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Description 

The present invention relates to data cryptography using control vectors. 

Various methods exist in support of electronic data security. Cryptography is the transformation of intelligible infor- 
mation into apparently unintelligible form in order to conceal the information from unauthorised parties. Cryptography is 
the only known practical method to protect information transmitted through communications networks that use land line, 
communications satellites, and microwave facilities. It can also be the most economical way to protect stored data. 
Cryptographic procedures can be used not only to protect the privacy of data, but also the integrity of data. 

A discussion of current techniques for the generation and distribution of cryptographic keys is given in the article in 
the ICL Technical Journal, Vol. 4, No. 2, November 1984, pp 146-158. 

The cryptographic transformation of data is ordinarily defined by a selected algorithm, or procedure, under the 
control of a key. Since the algorithm is normally public knowledge, protection of the transformed, or enciphered, data 
depends on secrecy of the key. Thus the key must be kept secret to prevent an opponent from simply using the known 
algorithm and key to recover the enciphered data. The protection of the data therefore hinges on the protection of secret 
keys. 

A new approach to key management is described in the above-mentioned co-pending European Patent Application 
No. 89308068.9. The invention disclosed herein deals with data cryptography which has as its objective the application 
of crytographic keys and methods to protecting the confidentiality and integrity of data via cryptography whereas the 
co-pending patent application deals with the generation, distribution, and management of the keys themselves. 

Prior art methods for encryption and decryption of data have evolved into complex sequences of key and data 
manipulations to thwart the attacks of an eavesdropper. These sequences have become so convoluted that security 
management of the secure system is difficult. Changing the security features of a processor or a system of processors 
is costly. What is needed is a better way to control usage of keys and the data encrypted by those keys. It is important 
for the system administrator to be able to specify the security features of the system, including the ability to maintain 
the separation of certain types of data and the corresponding keys. To maximise the security of the system, the admin- 
istrator should be able to do this on a dynamic, unannounced basis with ease. The system administrator must be able 
to enforce a security policy for the system which imposes restrictions on the users, the data, the keys and the crypto- 
graphic operations which can be performed. That enforcement should be easily implemented by the administrator and 
yet should be secure from subversion by an attacker. The features of flexibility and security have been difficult to achieve 
in the prior art. 

It is therefore an object of the invention to provide an improved method of data cryptography. 
This object is achieved by the invention claimed in claim 1 . 

The invention provides the basis of an improved data cryptography which controls the authorisation of users to 
encrypt, decrypt or authenticate data in accordance with a security policy established by the system manager and can 
be used to build into the storage of a key the authority to use that key in a manner which has been authorised by its 
priginator and to improve file security by providing the ability to encrypt a data file so that one portion is fully encrypted 
and another portion can be decrypted by authorised recipients. 

In the disclosed embodiment data cryptography is achieved in an improved manner by associating with the data 
cryptography key, a control vector which provides the authorisation for the uses of the key intended by the originator of 
the key. Among the uses specified by the control vector are limitations on encryption, decryption, authentication code 
generation and verification, and translation of the user's data. Complex combinations of data manipulation functions are 
possible using the control vectors, in accordance with the invention. The system administrator can exercise flexibility in 
changing the implementation of his security policy by selecting appropriate control vectors. 

Complex scenarios such as encrypted mail box, session protectbn, file protection, ciphertext translation centre, 
peer-to-peer ciphertext translation, message authentication, message authentication with non-repudiation and many 
others can be easily implemented by a system designer using the control vectors. 

The present invention will be described further by way of example with reference to an embodiment thereof as 
illustrated in the accompanying drawings in which: - 

Fig. 1 is a system diagram showing the major components of the Cryptographic Facility (CF); 

Fig. 2 is a system diagram showing the components of the CF, software driver CFAP and cryptographic application 
programs; 

Fig. 3 illustrates the fundamental cryptographic key separation; 
Fig. 4 illustrates data key separation; 
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Fig. 5 shows the general format for Control Vectors (CV); 
Fig. 6 shows the CV format for privacy keys; 
5 Fig. 7 shows the CV format for MAC keys; 

Fig. 8 shows the CV format for data compatability keys; 
Fig. 9 shows the CV format for data translate (XLATE) keys; 

10 

Fig. 10 shows the CV format for ANSI Data keys; 
Fig. 11. shows the CV format for intermediate ICVs; 
'5 Fig. 1 2 shows the CV format for tokens; 

Fig. 1 3 is a block diagram of the encode instruction; 
Fig. 14 is a block diagram of the decode instruction; 

20 

Fig. 15 is a block diagram of the encipher instruction; 
fig. 16 is a block diagram of the decipher instruction; 
25 Fig. 17 is a block diagram of the generate message authentication code (Genmac) instruction; 

Fig. 18 is a block diagram of the verify message authentication code (Vermac) instruction; 
Fig. 19 is a block diagram of the translate cipher text instruction; 

30 

Fig. 20 shows the electronic code book (ECB) mode of DES encryption; 
Fig. 21 shows the cipher block chaining (CBC) mode of DES encipherment; 
3S Fig. 22 shows the CBC mode of DES decipherment; 

Fig. 23 shows the message authentication (MAC) algorithm; 

Fig. 24 summarises the equations for each of the data instructions; 

40 

Fig. 25 shows the operation of session protection; 
Fig. 26 shows the operation of file protection; 
45 Fig. 27 shows the operation of encrypted mail box; 

Fig. 28 shows the operation of ciphertext translation centre; 

Fig. 29 shows the operation of peer-to-peer ciphertext translation; 

so 

Fig. 30 shows translating part of an encrypted file; 
Fig. 31 shows message integrity using control vectors; 
55 Fig. 32 shows message integrity with non -repudiation using control vectors; and 

Fig. 33 shows a message format. 
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The Cryptographic Architecture which underpins this invention enforces strict key separation within the local cryp- 
tographic facility and between systems by employing control vectors which force the recipient or user of a key to use 
the key in a manner consistent with the intentions of the originator of the key. 

The following cryptographic data management functions are provided by the arrangement disclosed herein: 

1 . Data Confidentiality. Data confidentiality protects the contents of a message or file form unauthorised disclosure. 
Applications of data confidentiality include the following: 

- Session Protection. Data encryption to protect the confidentiality or session level data transmission between 
two communicating devices. Each end user (device or application) shares a common data encrypting/decrypting 
key, thus permitting each end user to both send and receive encrypted data. 

- File Protection. Data encryption to protect the confidentiality of data files. A single end user (device or applica- 
tion) possesses a data encrypting/decrypting key permitting data to be encrypted for storage and to be decrypt- 
ed, at a later time, for purposes of recovery or access to the file. 

Encrypted Mail Box. The encrypted mail box describes a multi-user environment in which each user has a 
data/privacy key in two forms. The first form permits data encryption; the second form permits data decryption. 
The first form of the key is placed in a public directory or central registry accessible to all users of the system. 
Each so registered key is recorded under a user identifier belonging to the user who registers the key. The 
second form of the key is kept private by the user to which it belongs. Thus, a user i who wishes to send 
encrypted messages to user j, first requests user i's, encryption from the public directory. Data encrypted with 
this key is then sent to user i and placed in user i's mail box. User i can read received mail by decrypting first 
with his/her private decryption key. But since no other user has access to user i's decryption key, the environment 
is such that users can encrypt mail for each other user but only the authorised designated receiving user can 
decrypt and read his/her mail. 

-- Ciphertext Translation Centre (CTC). The ciphertext translation centre is a network node or device capable of 
securely translating encrypted data from encryption under a first data key to encryption under a second data 
key. In effect, the CTC possesses one or more data keys under which encrypted data may be received and one 
or more datas keys under which received encrypted data may be re-encrypted. These data keys thus establish 
a secure channel permitting the CTC to translate ciphertext from one key to another but not to decrypt ciphertext. 
The CTC may be further restricted from encrypting data with one or more of these data/privacy keys for the 
purpose of introducing data into the secure channel. 

Peer-to-Peer Ciphertext Translation. This environment consists of a chain of two or more CTCs which establish 
a secure channel from one set of network devices to another set of network devices. The first CTC in the chain 
possesses one or more data keys under which encrypted data may be received from the first set of network 
devices. Each CTC in the chain possesses one or more data keys under which encrypted data may be re-en- 
crypted, but not decrypted. The CTCs may be further restricted from encrypting data with one or more of these 
keys for the purpose of introducing data into the secure channel. The last CTC in the chain re-encrypts the 
encrypted data under one or more data keys shared with members of the second set of network devices. 

« Translate Part of an Encrypted File. This is an application wherein part of an encrypted file can be translated 
to a key which can be conveniently shared with an intended receiver. The method avoids sharing the original 
data/privacy key used to encrypt the file, since doing so may jeopardise the confidentiality of data not intended 
to be shared. 

2. Data Integrity. Data integrity protects the contents of message or file from unauthorised modification. This includes 
changes, additions, and deletions to the data. Cryptography provides only methods for detecting unauthorised 
changes to data. It cannot prevent unauthorised changes to data. 

3. Message Authentication. Message authentication is a procedure established between two communicants which 
allows each communicant to verify that received messages are genuine. Communicants can be people, devices, 
or processing functions. Message authentication allows the receiver of a message to determine that: 



The message originated with the alleged sender. 
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-■ The contents of the message have not been accidentally or intentionally changed. 

The message has been received in the same sequence that it was transmitted. 

5 - The message was delivered to the intended receiver 

In other words, message authentication permits the receiver to validate a message's origin, contents, timeliness, 
and intended destination. Applications of message authentication include the following: 

10 - Straight message authentication. 

b« Non-repudiation via MACGEN and MACVER. 

Fig. 1 gives a block diagram representation of the data processing system with the cryptographic facility therein. In 
'5 Fig. 1 , the data processing system 2 executes a program such as the crypto facility access programs and the application 
programs illustrated in Fig. 2. These programs output cryptographic service requests for data cryptography operations 
using keys which are associated with control vectors. The general format for a control vector is shown in Fig. 5. Control 
vectors define the function which the associated key is allowed by its originator to perform. The arrangment disclosed 
herein is an apparatus and a method for validating that data cryptography functions requested for a data set by the 
20 program, have been authorised by the originator of the key. 

As is shown in Fig. 1 , contained within or associated with the data processing system 2 is a cryptographic facility 4 
which is characterised by a secure boundary 6. An input/output path 8 passes through the secure boundary 6 for receiving 
the cryptographic service request, data, cryptographic keys and their associated control vectors from the program. The 
input/out path 8 outputs responses to those cryptographic requests from the cryptographic facility. Included within the 
25 secure boundary 6 is a cryptographic instruction storage 10 which is coupled by units of the bus 12 to the input/output 
path 8. A control vector checking units 14 is coupled to the instruction in storage 10 and a cryptographic processing 
units 16 is also coupled to the instruction storage 1 0. A master key storage 18 is coupled to the cryptographic processing 
unit 16. The cryptographic facility 4 provides a secure location for executing data cryptography functions in response to 
the received service request. 

30 The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for 

performing a data cryptography function with a cryptographic key. The control vector checking unit 14 has an input 
coupled to the input/output path 8, for receiving a control vector associated with the cryptographic key. The control vector 
checking unit 14 also has an input connected to the cryptographic instruction storage 10, for receiving control signals 
to initiate checking that the control vector authorises the data cryptography function which is requested by the crypto- 

35 graphic service request. 

The control vector checking unit 1 4 has an authorisation output 20 which is connected to an input of the cryptographic 
processing unit 16, for signalling that data cryptography function is authorised, the receipt of the authorisation signal by 
the cryptographic processing unit 16 initiates the performance of the requested data cryptography function with the 
cryptographic key. A cryptographic key storage unit 22 is coupled to the cryptographic facility 14 over the input/output 

^0 path 8. The cryptographic key storage unit 22 stores the cryptographic key in an encrypted form in which the cryptographic 
key is encrypted under a storage key which is a logical product of the associated control vector and the master key 
stored in the master key storage 18. 

An example of recovering an encrypted key from the cryptographic key storage 22 occurs when the cryptographic 
instruction storage 10 receives over the input/output path 8 a cryptographic service request for recovering the crypto- 

45 graphic key from the cryptographic key storage units 22. The control vector checking unit 1 4 will then output in response 
thereto, an authorisation signal on line 20 to the cryptographic processing unit 16 that the function of recovering the 
cryptographic key is authorised. The cryptographic processing unit 1 6 will then operate in response to the authorisation 
signal on line 20, to receive the encrypted form of the cryptographic key from the cryptographic key storage 22 and to 
decrypt the encrypted form under the storage key which is a logical product of the associated control vector and the 

50 master key stored in the master key storage 1 8. 

The storage key is the exclusive-OR product of the associated control vector and the master key stored in the master 
key storage 18. Although the logical product is an exclusive OR operation in the preferred embodiment, it can also be 
other types of logical operations. 

The associated control vector, whose general format is shown in Fig. 5, is stored with the encrypted form of its 

55 associated cryptographic key in the cryptographic key storage 22. Since all keys stored on a cryptographic storage are 
encrypted under the master key, a uniform method for encryption and decryption of encrypted keys thereon can be 
performed. 

The associated control vector, whose general format is shown in Fig. 5, includes fields defining the authorised types 
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of cryptographic functions, including data cryptography functions, data encryption/decryption functions and personal 
identification numbers (PIN) processing functions. In the data cryptography applications, the data cryptography functions 
type is designated for the type field. The associated control vector also includes additional fields which can define export 
control for the keys and associated encrypted information and the usage of the keys and associated encrypted infor- 
mation. 

The following provides a more detailed description of the components and operations of the disclosed arrangement. 

Fig. 2 shows the major components of a crypto subsystem. The cryptographic subsystem consists of a Crypto 
Facility (CF), Crypto Facility Access Program (CFAP), and Application Program (AP). Normally, the CF is implemented 
in hardware, inside a physically secure box. Depending upon the implementation, the CF, CFAP, and AP could all be in 
a physically secure box. 

The Cryptographic Facility 4 consists of: 

- Key Registers 

The registers and their usages are described below: 

~ Master Key Register 18: The master key register is 128 bits wide, containing the master key 

New Master Key (NMK) register: The new master key register is 1 28 bits wide, containing the new master key that 
is going to become the current master key. The New Master Key will become the current master key only after a 
special instruction, the SMK instruction is issued to load the value of new master key into the master key register. 

- Old Master Key Register: The old master key register is 128 bits wide, containing the master key that was replaced 
by the current master key. The master key update mechanism is such that the current master key becomes the old 
master key prior to the new master key becoming the current master key. 

- Key Part Register: The key part register is 128 bits wide, containing the value of a key part (component), or a 
complete key that is being installed via a key loading device such as a key pad or key board attached to the CF via 
an optional secured physical interface. 

- Working Key Register(s): For performance reasons, the system has working register(s), 128 bits wide each, to 
contain immediate working key(s) for fast accesses. For example, a key that is used to encrypt data is brought into 
the CF is encrypted form on the first use. It then is decrypted and the clear value can be stored in one of the working 
key registers. In subsequent uses to encrypt or decrypt the data, this clear key can be quickly accessed from a 
specific working key register, thus eliminating the repeated steps of decrypting the key prior to using it. 

- Program MDC Register (PMDC Reg): The program MDC register is 64 bits wide, containing the MDC of the program 
to be loaded in the program memory inside the CF. 

Dataset MDC register (DMDC Reg): The dataset MDC register is 64 bits wide, containing the MDC of the datasets 
whose integrity is validated by CFAP. This normally is, at least, the key storage datasets. 

Cryptographic instructions and control vector checking algorithms. 

The instruction set and control vector checking algorithms are implemented in the secured cryptographic facility 
and are stored in the cryptographic instruction storage 10 which is a random access memory. They are executed in a 
microprocessor such as an Intel 80286 which can serve as the cryptographic processing unit 16. The control vector 
checking unit 14 can also be implemented in the cryptographic processing unit 16 or it can be implemented by a second 
microprocessor such as an Intel 80286 serving as the control vector checking unit 14. 

Program Memory and Processing Engine 

The system can also employ a memory inside the CF to store user's programs and a processing engine to execute 
the programs. An example of this is a program or macro for performing new algorithms for PIN verifications on new PIN 
formats. 

Random Number Generator 26 

The random number generator is an algorithmic procedure for producing 64 bit pseudo random numbers. The al- 
gorithm itself is non-secret, but makes use of two 128 bit secret keys and a 64 bit non-secret incrementing counter. 
Although non-secret, the integrity and proper management of the counter are essential to security. 

The Crypto Facility (CF) is a secure implementation containing the Data Encryption Algorithm and storage for a 
small number of key and data parameters in the cryptographic instruction storage 1 0. It can be assessed only through 
inviolate interfaces (secure against intrusion, circumvention, and deception) which allow processing requests, key, and 
data parameters to be presented, and transformed output(s) to be received. 

The ANSI Data Encryption Algorithm (DEA) is a standard cryptographic algorithm for commercial data security 
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products. The DEA is a symmetric block cipher algorithm that uses a 56-bit secret key to encipher 64 bits of plaintext 
to form 64 bits of cipher text. DEA keys are normally stored with 1 parity bit per byte, forming a 64-bit key. DEA forms 
the basis for the National Bureau of Standards approved Federal Data Encryption Standard, so it is also called DES. 

The cryptographic facility must resist probing by an insider adversary who has limited access to the cryptographic 
hardware. "Limited" is measured in minutes or hours as opposed to days and weeks, and the adversary is constrained 
to a probing attack at the location where the system is installed, using limited electronic devices as opposed to a labo- 
ratory attack launched at a site under the control of the adversary using sophisticated electronic and mechanical equip- 
ment. 

The cryptographic facility must detect attempts at physical probing or intrusion. This may be accomplished using a 
variety of electro-mechanical sensing devices. 

The cryptographic facility must provide for the automatic zeroing of all internally stored clear keys. Such zeroing 
must be performed automatically whenever an attempted probing or intrusion has been detected. The cryptographic 
facility must also provide a manual capability to zero key storage via the front panel interface. 

The crypto facility contains one master key KM. All other keys can reside on mass storage encrypted under a key 
formed by Exclusive ORing the master key with a valid control vector. 

U.S. Patent 4,386,234 entitled "Cryptographic Communications and File Security Using Terminals" describes an 
sample Cryptographic Facility. 

The CFAP is the programming interface between the CF and the application program. Since users do not have 
direct access to the cryptographic facility, the CFAP is the programming interface through which the users can request 
the CF to perform specific operations. 

Associated with the CFAP is the Key Storage outside the CF where encrypted keys are stored. No clear keys are 
stored outside the CF. The Key Storage 22 is also referred to herein as the "Cryptographic Key Data Set" (CKDS). 

The CFAP typically consists of the following: 

Key Storage Manager to manager keys stored in the key storage mentioned above. 
- CFAP Macros through which users access to the CF to perform cryptographic functions. 

Application programs include user's application programs, some utilities such as a key installation utility, and com- 
munication programs such as IBM VTAM. 

User's application programs consist of statements that will invoke certain CFAP macros to perform a specific task. 
As mentioned, the CFAP is the only interface through which application programs can request CF to execute a crypto- 
graphic operation. For example, a user might want to encipher a file prior to shipping it to another node on the network. 
His application program might have one statement that calls a CFAP macro to generate a key, and another statement 
that invokes another CFAP macro to encipher the data of the file with the given key. 

Another example of a user's application program is one that allows the manual installation of keys on the system, 
similar to the installation program mentioned above. 

Notation - The following notation is used herein: 
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Electronic code book r 
Cipher block chaining 
128 bit Master key 
128 bit Key encrypting key 
64 bit key 
128 bit key 
64 or 128 bit key 
64 bit data encrypting key 
64 bit Key encrypting key 
128 bit Key encrypting key 
offset 64 bit Key encrypting key 
offset 128 bit Key encrypting key 
offset 64 or 128 bit Key encrypting key 
128 bit partial notarising Key encrypting 
key 

128 bit notarising key r equivalent to 

*KKHIo 
64 bit control vector 
64 bit left control vector 

30 



35 



40 



45 



50 



55 



20 



25 



ECB 

CDC 

KM 

KEK 

K 

*K 

(*)K 
KD 
KK 
*KK 
KKo 
*KKo 
(*)KKo 
•KKNI 

*KN 

cx 
CxL 
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CxR 64 bit right control vector 

XOR or xor exclusive or operation 

or logical or operation 

X '0' Hex notation 

11 concatenation operation 

W optional parameter x 

not = not equal 

E or e single encryption 

D or d single decryption 

EDE or ede triple encryption 

DED or ded triple decryptipn 

Equations The function of each instruction is mathematically 

denoted in the form: 

II, 12, 13, 14,. 01, 02, 03,... 

where II, 12, 13,.,. are the inputs to the function and 
01, 02, 03,... are the outputs from the function. 
KM.Cx (KML XOR Cx) 11 (KMR XOR Cx) = KMY 11 KMX 

where, KML = Left 64 bits of the master key 
KM, 

KMR = right 64 bits of the master key 

KM, 

KMY = KML XOR Cx 
KMX = KMR XOR Cx 
e*KM.Cx(key) e*KM.Cx(key) = eKMY (dKMX(eKMY (key) ) ) 
where, KMY = KML XOR Cx 
KMX= KMR XOR Cx 
key = 64 bit key 
e*KEKn.CX(key) e*KEKn . Cx (key) « eKEKY ( dKEKX ( eKEKY (key) ) ) 
where, KEKY = KEKnL XOR CxL 
KEKX = KEKnR XOR CxR 
key = 64 bit key 
e*KM.CxL ( KEKnL )e*KM. CxL (KEKL) = eKMY) dKMX (eKMY (KEKnL) ) ) 
where, KEKL - left 64 bits of KEK 
KMY = KML XOR CxL 



9 



EP 0 354 774 B1 



KMX = KMR XOR CxL 
e*KM.CxR(KEKnR)e*KM. CxR (KEKR) = eKMY (dKMX (eKMY (KEKnR) ) ) 
where r KEKR * right 64 bits of KEK 

KMY = KML XOR CxR 

KMX * KMR XOR CxR 
e*KEKo(key) e*KEKo(key) « eKEKLo {dKEKRo (eKEKLo (key) 
where, KEKLo - KEKL XOR cntr 

KEKRo = KEKR XOR cntr 

cntr « implicit 64-bit key-message 

counter for KEK 

key = 64- bit key 

Cryptographic Separation of Keys 

Keys are separated cryptographically according to key type and key usage attributes. 

- 1 . The architecture guarantees that cryptographic keys can be used only in the way or ways prescribed and intended. 

2. Internal Versus On-The-Link Separation. Internally (i.e., within the cryptographic facility), keys are separated via 
control vectors or other appropriate/equivalent mechanism. On the link, keys are separated using control vectors. 

3. Hardware Versus Software Enforcement. Certain cryptographic separation is implemented in hardware; other 
cryptographic separation can be implemented via software. 

- 4. Control vector key types and compatibility-mode key types. In order that the compatibility-mode key types will 
not diminish the security, certain rules governing generation, distribution, and usage of these two classes of key 
types is imposed 

- 5. A list of required key separations provided by the invention is listed below: 

Data Privacy ENCIPHER from DECIPHER, allows public key protocols such as mailbox, ballot and pass on. 

- Data MAC. MACGEN from MACVER, allows for non-repudiation (equivalent of electronic signature). 

Data XLATE. Allows a secure translate channel to be established, where intermediate devices cannot decrypt 
encrypted data. 

- Data COMPAT. Allows compatibility mode without weakening security of other data keys. 

- Data ANSI . Allows ANSI X9. 1 7 data cryptography to be coexist with non-ANSI X9. 1 7 data cryptography without 
loss of security to either approach. 

-- Key Encrypting Keys. KEK Sender from KEK Receiver. 

- PIN Keys. PIN Generating-Key from PIN Encrypting Key. 

The following notation is used for Figs. 3 and 4: 

Near each line leaving a box is a separation letter and a priority number. 

The separation letter will correspond with descriptions below: 

The range of priority numbers (1 through 4) should be interpreted as follows: 

-- 1 . Absolute necessity 
-- 2. Strongly recommended 

- 3. Recommended 
4. Desirable 

Fundamental Key Separation 

Fig. 4 illustrates the fundamental cryptographic key separation. An explanation of the separation is given below: 
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- 1 . A. Data Keys : KEKs and PIN keys 

If KDs (Data Keys) are not separated from KEKs and PIN keys, then Decipher data function used with data keys 
could be misused to decipher KEKs and PINs. 

5 

- 2. B. Key Encrypting Keys : PIN keys 

If KEKs (Key Encrypting Keys) are not separated from PIN Keys it would be possible for an outsider to wiretap an 
encrypted PIN block and replay it in place of an encrypted KD. Ahead of time, an insider accomplice could replace the 
10 encrypted stored KEK with the encrypted stored PIN Key in the receiving node's cryptographic key -data set. The PIN 
block would be then recovered and used as a data key at the receiving node. Subsequently, data that would be encrypted 
under this PIN block used as a data key would be much easier to subject to a key exhaustion attack as the variability 
of PINs (normally four to six decimal digits) is much less than that of a random 56 bit data key. 

'5 Data Keys Separation 

Fig. 4 shows the flow chart of the Data keys separation. The justifications for the separation are given below. 

- 1 . A - Authentication : Privacy 

An insider who can collect plain and corresponding ciphertext encrypted with a MAC key can perpetrate an attack 
against the MAC procedure. For example, it would be possible to construct fraudulent messages and MACs that would 
be authenticated and accepted by the MAC algorithm. Thus, the data keys used for encryption/decryption should not 
be used for authentication of data. 

On the link, if an intercepted data key can be substituted for a MAC key, the transmitted ciphertext (under that data 
key) could be used to construct a fraudulent message and MAC. 

- B - Xlate Ciphertext : Privacy 

By definition, Xlate Ciphertext implies the use of a pair of data keys KD1 and KD2, where ciphertext encrypted under 
KD1 is decrypted under KD1 and then re-encrypted under KD2 without exposing the data to the calling application 
program. Otherwise, Xlate Ciphertext could be performed using the existing Decipher and Encipher functions. 

-- C - ANSI : all others 

35 

ANSI keys have their own protocol for key distribution and an additional possible usage referred to as ANSI COM- 
BINE KEYS. These differences mandate a separate pool for all ANSI keys. 

- D - Data COMPATIBILITY ■ All others 

40 

Data Compatibility keys exist due to requirements to be compatible with prevbus systems such as IBM CUSP/3848, 
IBM PCF, and IBM 4700. As the enforced internal separation in these systems does not extend to the level of separating 
MAC from Privacy keys, these keys need to be distinguished from the CV keys which support such an improved level 
of separation. 

45 

- 2. B - MACGEN : MACVER 

Provides an audit trail to "prove" who originated a message and MAC (called non-repudiation). This method is no 
more secure than the CF, and assumes a mutual trust in the integrity and secrecy of keys stored in the CF. 

so 

- 3. C - Encipher : Decipher 

Provides true separation of the encipher and decipher functions, thus permitting data to be enciphered under a data 
key without exposing the right to decipher under that same data key For example, an encipher only data key could be 
55 used in a Vote and pass on' balloting scheme. A decipher only data key could be used in an environment where a user 
is authorised to read but not write some data. 
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Control Vectors 

The control vector is a 64 bit non-secret cryptographic variable for controlling the usage of keys. Each key K defined 
to the cryptographic system has an associated control vector C, i.e., the key and control vector define a tuple (K, C). 

Each control vector specifies a CV-TYPE, which broadly defines how the key may be used and the rules governing 
how that key may be communicated on the link. A key may be a data key, sender key encrypting key, receiver key 
encrypting key, PIN encrypting key, PIN generating key, Intermediate ICV, Key part or Token. Additional bits in the control 
vector specify exactly in which cryptographic instructions and parameter inputs the key may operate. Still other bits 
control the export of the key, i.e., whether the key can be exported or not. 

The control vector is coupled cryptographically to the key via a special encryption function. For example, when the 
K is stored in a Key Storage, K is encrypted under a key formed by Exclusive-ORing the control vector with the master 
key, i.e., K is stored as the tuple (eKM.C(K), C) ( where KM.C denotes KM xor C. When K is transmitted on the link (from 
one device to another), a similar encrypted form is used. In this case, the master key KM is replaced by a key encrypting 
key KEK, where KEK is a key shared between the sender and receiver. Thus, K is transmitted as the tuple ( eKEK.C 
(K), C). The architecture does not require that the control vector be stored or transmitted with the key in situations where 
its value is defined implicitly from the context or can be reconstructed from available key-related information. 

Since the control vector (C) is tightly coupled to the key (K), via the encrypted form eKM.C(K) or eKEK.C(K), it is 
apparent that K cannot be recovered from its encrypted form unless C is correctly specified. Thus, if the tuple (eKM.C 
(K), C) is provided as an input to a requested cryptographic instruction, the cryptographic facility will first check the 
supplied value of C to determine that the requested usage of the key is permitted. Only then will C be used to decrypt 
eKM.C(K) to recover the clear value of K internal to the cryptographic facility. If a false value C* is specified, the cryp- 
tographic facility may be fooled temporarily into accepting C*, but K will not be recovered properly. Thus, there is no 
opportunity for a user to recover the correct value of K unless the correct value of C is also specified. The cryptographic 
principle is thus the basis upon which the entire architecture is built; and additional security is provided as necessary 
and where appropriate. 

The control vector is a compact data structure for defining the usage attributes of a cryptographic key. The control 
vector is cryptographically coupled to the key via an encryption process. This process is such that the key can be de- 
crypted properly only if the control vector is correctly specified. (Even a single bit change in the control vector will cause 
an entirely different key to be recovered. 

- CV Checking 

The control vector is designed to minimise CV checking. Control vector usage bits are defined and structured so 
that each usage attribute, by itself, grants or denies a specific usage. Thus, the capability to encipher data via the 
Encipher Data instruction is controlled via a single "Encipher" bit within the control vector whose type/subtype is "da- 
ta/privacy". 

Thus, each usage attribute is defined independently from all other usage attributes. This guarantees a CV checking 
process such that each instruction checks only the usage attributes called for by the requested function. A design wherein 
usage attributes are enabled only when certain other attributes are enabled or disabled is specifically avoided, since 
this increases CV checking. Some cross checking of attributes among two or more control vectors is required, but is 
kept to a minimum. 

To facilitate and simplify CV checking, each cryptographic instruction, where necessary, is passed a "mode" param- 
eter declaring a specified use of the key or keys passed as parameters to the instruction. Thus, the C V checking process 
tests each control vector according to the specified "mode". This eliminates costly cross checking among control vector 
attributes to ensure consistency. 

The design also follows a principle that no cryptograph ic instruction generates a control vector. All control vectors 
are supplied to the cryptographic instructions as parameter inputs. 

Where possible, like usage attributes and field definitions are located at the same bit positions in the control vector, 
regardless of CV type. This facilitates CV checking. For example, the translate ciphertext instruction interrogates the 
same bit positions in the data/privacy and the data/xlate control vectors, even though the usage bits are "E 1 and "D" for 
the data/privacy CV and "XOUT" and "XI N" for the data/xlate CV, respectively. 

- CV Structure 

In general, the control vector structure (including formats, field and bit assignments) has been defined to minimise 
and to facilitate CV checking, while at the same time providing cryptographic security. The CV structure, so to speak, is 
the variable with the greatest degree of freedom in the design process. 

The following design options have been employed in the control vector: 
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- 1. Vertical Separation. 

The control vector has a "CV Type" field that provides vertical separation within the control vector structure, much 
like the separation provided by variants. Control vector types are defined along intuitive lines, following existing key 
terminology and data cryptography. However, vertical separation is implemented only where necessary under the CA, 
thus ensuring architectural simplicity and ease of comprehension of the CV checking rules. 

By first defining broad classes of CV Main Types (e.g. Data Keys, Key Encrypting Keys, PIN Keys) and then further 
defining CV Subtypes and usage attributes within CV Type, the CV checking rules can be optimised much in the same 
way that a "divided and conquer" search can be employed more effectively than a brute force approach. 

-- 2. Horizontal Separation. 

The control vector is ideally suited as a data structure for recording the usage attributes to be associated with a key 
(or other cryptographic variable). Within the CA, this is accomplished by specifying a bit in the control vector for every 
cryptographic instruction (or key parameter within the instruction, if more than one key parameter may participate) where 
the key may be used as an input. A bit value of "1" signifies that a usage of the key is "enabled" by the CF whereas a 
bit value of "0" signifies that a usage of the key is "disabled" by the CF This form of control vector structuring is called 
horizontal separation. 

-- 3. Encoded Fields. 

A field of two or more bits is sometimes encoded for reasons of security. An encoded field has the property that 
individual bits have no significance by themselves, but the bits together define a set of possible values. Encoded fields 
have the advantage that they define mutually exclusive events since the field can take on only one value at a time. 
Encoded fields have the potential disadvantage that CV checking is not always optimised from a performance standpoint. 
However, encoded fields are sometimes necessary to ensure that usage attributes cannot be mixed in inappropriate 
combinations that give rise to cryptographic attack or introduce some cryptographic weakness. 

~ 4. Protection From Non-System Generated Keys. 

The method for coupling the control vector and key is such that C V checking is unable to detect a system generated 
key (via KGEN or GKS) from a non-system generated key. For this reason, a "back-door" method exists within the 
architecture for generating a keys and control vectors. It consists of defining a control vector "of choice" and a random 
number which is then represented as a key encrypted in the manner described under the architecture using the selected 
control vector. (However, the method has no capability to control the key actually recovered within the cryptographic 
facility.) 

The so-called "back-door" method of key generation is primarily an annoyance, although in some cases crypto- 
graphic attacks would be possible if additional measures of defence were not taken in the architecture. It would be a 
simple matter to define an architecture that eliminates this "back-door" key generation (once and for all), but doing so 
would introduce additional unwarranted complexity and processing. A more practical approach is followed by the CA, 
viz., the "back-door" key generation problem is prevented only where necessary for security reasons. Thus, a good 
balance among security, complexity, and performance is achieved. Techniques to avoid cryptographic weaknesses in- 
troduced by the "back-door 0 method of key generation are these: 

— Where necessary, conflicting usage attributes within a single control vector are split among two control vectors. The 
GKS instruction has checking that prevents so-called bad combinations of key pairs from being generated. 

— Where necessary, conflicting usage attributes within a single control vector are grouped into a single encoded field. 

— As a last resort, extra redundancy is used so that the CF can validate its own system generated keys. 

— 5. Even Parity for Control Vectors. 

Even parity is enforced on the control vector. This ensures that the Exclusive-OR of an odd parity key with the control 
vector will result in an internal key of odd parity. This, in turn, ensures compatibility with hardware that may check such 
internally derived keys for odd parity (if such checking is enforced). Saying it another way, the CA cannot ensure that 
hardware will not enforce this odd parity on internal keys. 

A control vector of 64 bits, numbered 0 through 63. The most significant bit is bit 0, by convention. Of the 64 bits, 
there are 8 parity bits. 
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-- 6. Anti-Variant Bits. 

This guarantees cryptographic separation between variants and control vectors, which may unavoidably be mixed 
in some implementations internal to a node. 

5 

-- 7. Avoid Onto Mappings. 

The control vector design and the manipulation of the control vector via the cryptographic instruction set avoids 
instances where CV fields with multiple values are mapped into a single value. Some specific instances of such onto 
10 mappings are allowed (e.g., LCVA, RFMK, and RTMK instructions) where security is not jeopardised. 

- CFAP Control 

Certain bits in the control vector are reserved for CFAP. These bits can be used by CFAP for further data cryptography 
15 control. These bits are not checked by the CF, but are entirely managed by CFAP. 

- General Format for Control Vectors 

Fig. 5 shows the general format for control vectors. The first row of of Fig. 5 shows the fields that are in common 
20 for most of the control vectors. They are briefly described as follows: (Further details can be found in subsequent sub- 
sections.) 

CV Type 

25 This field indicates the type of control vector, and is also the key type of the key to which this control vector is 

attached. The CV Type field consists of main-type and sub-type. 
The main types of a control vector are: 

Data key: Data keys are used to encrypt/decrypt data, or to authenticate data. 
30 - pi n key: PIN keys are used to encrypt PI Ns or to generate PINs. 

- Key-encrypting key: Key-encrypting keys are used to encrypt keys. 

» Key part: A key part is a part or a component of a key, having the same length as the key. For example, a key K 
may have two key parts Ka and Kb such that Ka XOR Kb = K. 

- Intermediate ICV: An Intermediate ICV is used during MAC processing to encrypt the intermediate Output Chaining 
35 Value of a segment of data or message. This OCV is then fed into the next segment of the data and used as an 

ICV. This occurs when a message or data on which a MAC to be generated or verified is long and must be divided 
into shorter segments. 

Token: Tokens are variables used to protect the integrity of the data keys stored in the Data Key Dataset (a key 
storage for Data keys). They help prevent the access of data keys by unauthorised users. 

40 

The sub type differentiates the classes of keys of the same main type. For example, a key of main type data key 
can have the sub type of privacy (capable of doing encryption and decryption); or MAC (capable of doing data authen- 
tication); or XLATE Data (capable of translating ciphertext); etc. When no sub-type distinction is made, the keys are 
normally referred by the main type (e.g., Data key, PIN key, etc.) 

45 

- Export Control: This field indicates how the export of the key associated to this control vector is controlled, and 
whether the key is allowed to be exported. 

- CF Enforced Usage: This field indicates for what CA functions the key can be used, and how it is used. For example, 
a data privacy key may have the usage attributes E=1 and D=1, which indicate that the key can be used in the 

50 Encipher and Decipher function to encrypt and decrypt the data, respectively. 

- AV (Anti-Variant): This field differentiates any valid control vector from the 64 predefined variants that are used in 
variant-based crypto systems. Since all 8 bytes of the any variant of the 64 predefined variants are the same, setting 
the value of the AV field such that at least two bytes of the control vector are not the same will differentiate a valid 
control vector from a predefined variant. 

55 ~ Software Bits: This field represents control vector bits that are controlled/managed entirely by CFAP; The software 
field is not checked/enforced by the hardware (CF). When no control vector exists, CFAP builds a control vector 
from information supplied to CFAP (normally via parameter in a macro). When a control vector already exists, CFAP 
will check the control vector (including the software field) to determine whether the key is allowed to operate in the 
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manner specified/requested. The hardware (CF), unlike software (CFAP), checks only those bits associated with a 
CA instruction, other usage bits are not checked). 
~ Extension: This field indicates whether the control vector is a 64 bit control vector or an extended control vector of 
128 bits. In the current CA, all the control vectors have 64 bits in length. This field is defined now to ease the 
5 expanding of the control vector in the future when the number of bits required to specify the control vector exceeds 

the b4 bit length. 

-- Reserved Bits: This field is reserved for the system for future use. 

- Parity Vector: Every parity bit is the even parity of the preceding 7 bits of the byte. 

10 For key-encrypting key control vectors, besides the common fields listed above, there are two additional fields, KEY 

FORM and LINK CONTROL. 

- Key Form: This field indicates the length of the key (single or double length) and whether the key half associated 
with the control vector key is the right or left half of the key. Note that for a single length key, the right half is the 
same as the left half and is the key itself. 

- Link Control: This field indicates how the key-encrypting key associated to this control vector is used to transmit 
other keys on the link, and what type of system (e.g., CV system or non-CV system) can keys be shipped to or 
received from , under this key-encrypting key. 

20 NOTE: The descriptions in the second row and the third row in the general figure and other referenced figures in 

this section are not part of the control vector They are put there to give information on the fields of the control vector 
as follows: 

- The second row indicates the bit length of the fields. The abbreviation 'b* stands for 'bit' . For example, 1 b stands for 1 
25 bit, 3b stands for 3 bits, etc. 

- The third row indicates whether the field is checked by hardware 
(CF) or software (CFAP). 

Control Vector Format for Data Key 

30 

Data keys are divided into the following subtypes: 

Data Compatibility Key. This is the data key that would be used to maintain compatibility with existing systems such 
as IBM 3848/CUSP or IBM 4700 FCS. Since these existing systems do not have the cryptographic separation 
between privacy and authentication, this key can be used to perform any or all of the following functions: encipher, 
decipher, generate MACs and verify MACs. This control vector can be removed (i.e., substituted by CV=0on-the-link) 
when it is exported to other systems (via the RFMK instruction), whereas the control vectors for all other data keys 
except ANSI data keys cannot be removed. 

Privacy Key. This is the key used for enciphering and/or deciphering only. 

MAC Key. This is the key used for the purpose of data authentication only. That is, it can onfy be used to generate 
MACs and/or verify MACs. 

Data Translation Key (Data XLT Key). This is the key used in the translation of ciphertext. 
ANSI Key. This is the key that is used in ANSI applications. It can be used to encipher and decipher data or to 
generate and verify MACs. It can also be combined with another ANSI key to form an ANSI MAC key (i.e., a Data 
ANSI key with generate MAC/verify MAC capability). This control vector can be removed when exported to other 
systems (i.e., substituted by CV=0 on-the-link) via the ARFMK instruction, whereas the control vectors for all other 
data keys except compatibility keys cannot be removed. 

Depending on the CV subtype of the control vector, the bits in the USAGE field have specific meaning to be described 
so shortly. 

Control Vector for Privacy Keys 

Referring to Fig. 6, the following is a detailed description of each field and subfield of the figure. 

55 

- CV Type 

CV Type for privacy key (main type="DATA KEY", subtype="PRIVACY". 
Export Control (controls exporting of this key): This field occupies 1 bit: 
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-- EXPORT CONTROL = 1: This key can be exported by RFMK. Also, the RFMK, RTMK and LCVA instruction 
can reset this bit to 0. 

EXPORT CONTROL - 0: This key cannot be exported by RFMK. Also, it cannot be changed to 1 by any in- 
struction. 

As an example, suppose node X generates a key K and control vector C and sends them to node Y 
Usage 
E 

— =1: This key can be used in the ENCIPHER instruction to encrypt the data. 

— =0: Tnis key cannot be used in the ENCIPHER instruction to encrypt the data. 

D 

— =1: Tnis key can be used in the DECIPHER instruction to decrypt the data. 
~ =0: This key cannot be used in the DECIPHER instruction to decrypt the data. 

- AV (Anti-Variant) 

This field occupies two bits, used to differentiate the control vector from 64 predefined variants that are used in 
variant-based crypto systems. Since all 8 bytes of the any variant of the 64 predefined variants are the same, setting 
the value of the AV field such that at least two bytes of the control vector are not the same will differentiate a valid control 
vector from a predefined variant. 

- Software bits 

This field occupies 12 bits. 

- CV Version 

This field is 6 bits long and is used by CFAP to distinguish the current control vector definition from future definitions. 

- Software - Enforced Usage (See also the CFAP section.) 

- CVDPIM (Control Vector Data Privacy ICV Mandatory) 
» CVDPCU (Control Vector Data Privacy CUsp) 

» CVDP47 (Control Vector Data Privacy 4700) 

- CVDPM8 (Control Vector Data Privacy Multiple of 8) 

Extension 

This field indicates whether the control vector is a 64 bit control vector or an extended control vector of more than 
64 bits. 

- Reserved bits 

This field is reserved for the system for future use. 

- Parity 

This field consists of the last bit of every byte of the control vector. The parity bit of each byte is set to achieve even 
parity for the byte. 

Control Vector for MAC keys 

Referring to Fig. 7, the following is a detailed description of each field and subfield of the figure. 
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- CV Type: 

CV Type for MAC key (main type=:DATA KEY", sub type ="MAC"). 

- Export Control (controls exporting of this key): 

Same description as that of Privacy keys. 

Usage 

~ MG 

— - =1 : This key is permitted to be used in the GMAC instruction to generate MACs on data. 

— - =0: This key is not permitted to be used in the GMAC instruction to generate MACs on data. 

MV 

— =1 : This key is permitted to be used in the VMAC instruction to verify MACs on data. 

— =0: This key is not permitted to be used in the VMAC instruction to verity MACs on data 

- AV (Anti-Variant) 

Same description as that of Privacy keys. 

- Software bits 

This field occupies 12 bits. 
CV Version 

CV TYPE for MAC key (main type=:DATA KEY", sub type ="MAC"). 

- Software-Enforced Usage (See also the CFAP section) 

-~ CVDML4 (Control Vector Data MACLEN = 4) 

- CVDM99 (Control Vector Data MAC MODE = ANSI X 9.9) 

- CVDM19 (Control Vector Data MAC MODE = ANSI X 9.19) 

- CVDM00 (Control Vector Data MAC MODE = IBM 4700) 

- CVDM30 (Control Vector Data MAC MODE = IBM 4730) 

- Extension 

Same description as that of Privacy keys. 

- Reserved bits 

Same description as that of Privacy keys. 

- Parity bits 

Same description as that of Privacy Keys. 
Control Vector for Data Compatibility Keys 

Referring to Fig. 8, the following is a detailed description of each field and subfield of the figure. 
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-CVType 

CV TYPE = for data compatibility key (main type="DATA KEY", sub type ^COMPATIBILITY" 

- Export Control 

Same description as that of Privacy keys. 

Usage 

-- E 

— =1 : This key can be used in the ENCIPHER instruction to encrypt the data 
~ =0: This key cannot be used in the ENCIPHER instruction to encrypt the data. 

- D 

— =1 : This key can be used in the DECIPHER instruction to decrypt the data. 

— =0: This key cannot be used in the DECIPHER instruction to decrypt the data. 

MG 

— =1 : This key can be used in the GMAC instruction to generate MACs on data. 

— =0: This key cannot be used in the GMAC instruction to generate MACs on data. 

- MV 

— =1 : This key can be used in the VMAC instruction to verify MACs on data. 

— =0: This key cannot be used in the VMAC instruction to verify MACs on data. 

AV (Anti-Variant) 

Same description as that of Privacy keys. 
Software bits 

This field occupies 12 bits. 

- CV Version 

Same description as that of Privacy keys. 

- Software-Enforced Usage 
Extension 

Same description as that of Privacy keys. 
Reserved bits 

Same description as that of Privacy keys. 
Parity bits 

Same description as that of Privacy keys. 
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Control Vector for Data XL ATE key 

Referring to Fig. 9, thehe following is a detailed description of each field and subfield of the figure. 
s -CVType 

CV Type for data XLATE key (main type= B DATA KEY", sub type="XLATE B ) 

- Export Control (controls exporting of this key) 

Same description as that of Privacy keys. 
Usage 
is - XDout 

— =1 : This key is permitted to be used as the output data key in the TRANSLATE CIPHERTEXT instruction. 

— =0: This key is not permitted to be used as the output data key in the TRANSLATE CI PHERTEXT instruction. 

20 ~ XDin 

— =1 : This key is permitted to be used as the input data key in the TRANSLATE CIPHERTEXT instruction. 

— =0: This key is not permitted to be used as the input data key in the TRANSLATE CIPHERTEXT instruction. 

25 - AV (Anti-Variant) 

Same description as that of Privacy keys. 

- Software Bits 

30 

This field occupies 12 bits 

- CV Version 
Software-Enforced Usage - None. 

35 

• Extension 

Same description as that of Privacy keys. 
*o - Reserved Bits 

Same description as that of Privacy keys. 

- Parity Bits 

45 

Same description as that of Privacy keys. 
Control Vector for ANSI Data Keys 
50 Referring to Fig. 16, the following is a detailed description of each field and subfield of the figure. 

-CVType 

CV Type for data ANSI key (main type="DATA KEY", sub type ="ANSI 0 ) 

55 

- Export control 

Same description as that of Privacy keys. 
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- Usage 



5 - e 

— =1 : This key can be used in the ENCIPHER instruction to encrypt the data. 

— =0: This key cannot be used in the ENCIPHER instruction to encrypt the data. 

w - D 

— =1 : This key can be used in the DECIPHER instruction to decrypt the data. 

— =0: This key cannot be used in the DECIPHER instruction to decrypt the data. 

15 „ MG 

— =1: This key can be used in the GMAC instruction to generate MACs on data. 

— =0: This key cannot be used in the GMAC instruction to generate MACs on data. 

20 - MV 

— =1 : This key can be used in the VMAC instruction to verify MAC on data. 

— =0: This key cannot be used in the VMAC instruction to verify MAC on data. 

25 - ACMB 

This bit indicates whether the data key can be XORed with another data key having the ACOMBKD attribute. The 
, XORing process is done by the ACOMBKD instruction, as will be described in section "ANSI Combine KDs (ACOMBKD). ■ 
The resulting key is used to verify and generate MACs for the messages communicated via the ANSI X9.17 protocol. 

30 

- =1 : This data key can be combined in the ACMB instruction. 

- =0: This data key cannot be combined in the ACMB instruction. 

- AV (Anti- Variant) 

35 

Same description as that of Privacy keys. 

- Software Bits 
40 ~ CV Version 

Same description as that of Privacy keys. 

- Software-Enforced Usage - None. 

45 

- Extension 

Same description as that of Privacy keys. 
so - Reserved Bits 

Same description as that of Privacy keys. 

- Parity Bits 

55 

Same description as that of Privacy keys. 
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Control Vector Format for intermediate ICV 

Referring to Fig. 11, the following is a detailed description of each field and subfield of the figure. 
5 - CV TYPE 

CV TYPE, where the last three bits xxx of CV TYPE are set to zero but are not checked by the instructions (main- 
type="lntermediate ICV", subtype=Not applicable) 

10 - Export Control 

Same description as that of Privacy keys. The ICV keys are normally not imported to other nodes except in the case 
of a hot backup. Thus, normally, this field assumes the value B'OO' for an ICV control vector. 

'5 - AV (Anti- variant) 

Same description as that of Privacy keys. 

- Software Bits 

20 

~ CV VERSION 

Same description as that of Privacy keys. 
25 Software-Enforced Usage - None. 

- Extension 

Same description as that of Privacy keys. 

30 

- Reserved Bits 

Same description as that of Privacy keys. 
35 - Parity Bits 

Same description as that of Privacy keys. 
Control Vector Format for Tokens 

40 

Referring to Fig. 12, the following is a detailed description of each field and subfield of the figure. 

- CV TYPE 

45 CV TYPE, where the last three bits xxx of CV TYPE are set to zero but are not checked by the instructions (main- 

type="Token", subtype=Not applicable). 

Tokens are secret quantities used to protect the integrity of Data keys stored in the Data Keys Dataset (DKDS). 
Data keys are stored in the DKDS in the form token+e*KM.C1 (K),e*KM.C2(token). Token control vector type is allowed 
in several instructions such as EMK, RTNMK and RTCMK. 

so 

- Export Control 

Same description as that of Privacy keys. The ICV keys are normally not imported to other nodes except in the case 
of a hot backup. Thus, normally, this field assumes the value B'OO* for an ICV control vector. 

55 

- AN (Anti-Variant) 

Same description as that of Privacy keys. 



21 



EP 0 354 774 B1 



- Software Bits 
-- CV VERSION 

Same description as that of Privacy keys. 
~ Software-Enforced Usage - None. 

- Reserved Bits 

Same description as that of Privacy keys. 

- Extension 

Same description as that of Privacy keys. 

- Parity Bits 

Same description as that of Privacy keys. 
Instruction Set 

The instruction set described here is a common cryptographic function set which is implemented in the CF. There 
may be exceptions to this requirement; for instance, MDC can be implemented at a CFAP level. Other deviations in the 
instruction set implementation should be carefully considered based on security requirements and product environment. 

The instruction set is based on a control vector approach. There are several fields in the control vectors which may 
or may not be implemented in a particular system. However, the minimum control vector checking as described here 
must be performed in each system in the CF. If the full crypto separation is not required or only a subset of the instruction 
set is sufficient for a given application, the control vector checking can be excluded for the functions not implemented 
in a given design. (The checking on subtype fields in the control vector, an encoded field, ensures that control vectors 
can not be mixed and matched in the crypto instructions using invalid combinations. This checking is crucial to security.) 

The instruction set equations represent the inputs required to the function and outputs expected from the function 
related to a cryptographic function described. Instead of passing actual data to the function, the implementation may 
pass the addresses of data to the function. This addressing would depend upon the given system implementation and 
is not described here. 

The equations describe all the parameters and data required to perform a given function. Depending upon the 
modes of the operation, some or all the parameters are used in the function, however, the fields in the equation have 
to be treated as inputs and outputs rather than the actual values of inputs and outputs as passed to the function in a 
given implementation. For example: the "A" field in the equation represent the data to be passed to a function, the 
physical form of this may be a 32 bit address pointing to the data to be fetched by the instruction from memory or to be 
stored to the memory. The data bus width from memory is also implementation dependent, whereas the input data to 
be encrypted or decrypted by crypto function operations is always a multiple of 8 bytes. 

There are two fundamental ways in which CV checking can be done. 

- Test Bits in Control Vector: Test the control vector bits according to what they should be, if it does not match then set 
a condition code and abort the operation. 

For example, in ENCIPHER instruction 8 E" bit of the CV is tested for "1 \ if it is not one then the operation is aborted. 
For more complicated instructions, the testing is not as trivial as this, and we need to pass some parameters to specify 
the intent of input and output operation and the usage of control vector. For example, in generate key set (GKS), "mode 0 
is specified to the instruction to generate a particular from of output, and the control vector checking has to be performed 
according to the "mode" specification. 

- Set bits in Control Vector: Set a bit in control vector as appropriate then perform the operation. This does not require 
any testing of control vectors. 

For example, in ENCIPHER instruction "E" bit is set in the control and the operation is performed. Now, each in- 
struction has to know, what bits to set and under what conditions? This strategy may not work in all cases. For instance, 
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how would the instruction know what is the bit setting for "target control"? This means, there has to be a parameter 
specified to the instruction indicating to choose a particular setting in the control vector. This approach will take away 
all the flexibility in the control vector specification. 

Either of the above two techniques will satisfy the cryptographic requirements of the control vector checking. We 
s have chosen the Test bits in Control vector" approach (no bits in the control vector are set by the instruction) for the 
following reasons: 

Instruction does not have to know what bits to set nor when. 

It is very flexible to pass a parameter like "mode" and get the possible combination of outputs, and provide a com- 
10 bination of inputs to the instruction. 

If the setting is hardcoded in the CF, then it is very hard to make extension to the architecture, and it is also very 

difficult to know all the possible combinations ahead of time. 

It simplifies hardware implementation, and provides greater flexibility to software. 

It preserves the intent of control vectors: Control vectors (at the present time) are used for cryptographic separation 
*5 and specifically for security reasons. Control vectors are not used in CA for "specifying an operation or a function 

to the instruction". In other words, control vectors are not like an "extended opcode" for the instruction. 

Encode (ENC) 

20 - Equation: KD, A ===== eKD(A) 
Inputs: 

KD 64 bit clear key 
A 64 bit plain text 

25 

Outputs: eKD(A) 64 bit encrypted data 

Description: The encode function is used to encipher an 8 byte plain text data in ECB mode using a 64 bit clear key. 
No control vector is passed to this instruction. 
30 Fig. 1 3 is a block diagram of this instruction. 

- cc: 



35 

- 1 . successful operation 

- 2. unsuccessful operation (error) 

NOTE: Unsuccessful operation can be any hardware error specific to a given implementation. The condition codes 
40 (cc described here merely represent suggested condition codes for the instruction, however, there may be more condition 
cedes implemented in a given system. Furthermore, the CC codes do not represent the actual condition codes that have 
to be passed by the function in a given implementation, the numbering used here is for a convenient description of crypto 
architecture. 

45 - Control Vector Checking: - None. 

Decode (DEC) 

- Equation: KD, eKD(A) === A 
50 - Inputs: 

KD 64 bit clear key 
eKD(A) 64 bit encrypted data 

55 - Outputs: A 64 bit encrypted data 

Description: The decode function is used to encipher an 8 byte plain text data in ECB mode using a 64 bit clear key. 
No control vector is passed to this instruction. 
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Fig. 14 is a block diagram of this instruction. 

- CC: 

1 . successful operation 
- 2. unsuccessful operation (error) 

Control Vector Checking: - None 

Encipher (ENCI) 

- Equation: e*KM.C1 (KD1 ), ICV, A, n, C1 ===== eKDI(ICV,A) 
Inputs: 

e*KM.Ct (KD1 ) 64 bit data key (KD1) triple encrypted under the master key (KM) with a control vector C1 . 
ICV 64 bit plain input chaining value 

NOTE: Encrypted ICVs are managed by CFAP as described in the B ICV/CCV Management" and "Software Inter- 
face." 

If output chaining value (OCV) is required, the last 8 byte output (En) must be used as OCV, however, this is not a 
standard approach. Each system implementation treats the encryption and decryption of the last block differently. Refer 
to "Software Interface" for more details on the last block treatment and OCV generation techniques. CFAP handles all 
the possible last block encipherment and decipherment and also OCV management. 

A Data to be encrypted, in multiples of 8 byte blocks. 

The 8 byte blocks are Al, A2,...An. If the last block An is not a multiples of 8 bytes, padding should be performed 
by CFAP before calling this instruction. CF instructions always assume multiples of 8 bytes data as inputs and outputs. 

n number of 8 byte blocks to be encrypted. 

n should be as large as possible, however, this may be system dependent. CA does not define any maximum limit 
on a For example: If number of 8 byte blocks = 1 0,000 and n max = 4,000, then Encipher instruction will be invoked as 
follows: 

- Encipher n=4000 

- Encipher n=4000 

- Encipher n=2000 

NOTE: After each call of Encipher, the last 8 bytes enciphered data En (OCV) has to be fed back as ICV input to 
the next Encipher call. 

d 64 bit control vector for data key (KD1 ). 

- Outputs: ekDI(ICV,A encrypted data, n blocks, each block is 8 bytes (E1, E2..En). 

Description: The input data is encrypted via the CBC mode of DEA encryption. Multiples of 8 byte blocks are en- 
crypted by this instruction until all n blocks are encrypted. 

The architecture defines only plain ICV input to the function. If encrypted ICV is required, the ICV can be encrypted 
using a data key (KD2) using encipher instruction. Encrypted ICVs can be decrypted using decipher instruction. All the 
encrypted ICVs and OCVs are managed by the CFAP program. 

If the input data is not in multiples of 8 byte blocks then padding must be done. This padding has to be performed 
by CFAP before invoking the encipher function. 

Fig. 1 5 is a block diagram of this instruction. 

-CC: 
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- 1 . successful operation 

- 2. C1 is invalid 

- 3. unsuccessful operation (error) 

s - Control Vector Checking: 

- 1. Checking on C1 

— CV type = "data/compatibility 0 or "data/privacy - or "data/ANSI* 
10 — E usage bit = 1 

— reserved (48:63) = X'O' 

NOTE: For all the instructions described,here, control vector checking implies that if the check is not passed then 
the instruction must be aborted and the corresponding control vector invalid condition code (cc) be turned on. If there 
« are one or more checks to be performed on the control vectors, all the checks are performed and all the checks have 
to be passed to perform the operation. If any of the checks fail, the operation must be aborted. 

Decipher (DECI) 

20 - Equation: e*KM.C1(KD1), ICV, eKDI(ICV.A), n, C1 == A 
Inputs: 

e*KM.C1 (Kd1) 64 bit data key (KD1 ) triple encrypted under the master key (KM) with a control vector C1 . 
ICV 64 bit plain input chaining value. 

25 

NOTE: Encrypted ICVs are managed by CFAP as described in the "ICV/OCV Management" and 'Software Inter- 
face." 

If output chaining value (OCV) is required, the last 8 byte input (En) must be used as OCV, however, this is not a 
standard approach. Each system implementation treats the encryption and decryption of the last block differently. Refer 
30 to "Software Interface" for more details on the last block treatment and OCV generation techniques. CFAP handles all 
the possible last block encipherment and decipherment and also OCV management. 

eKdl (ICV, A) encrypted data, n blocks, each block is 8 bytes (E1 , E2..En). 
n number of 8 byte blocks to be decrypted. 

35 

n should be as large as possible, however, this may be system dependent. CA does not define any maximum limit 
on n. 

NOTE: After each call of Decipher, the last 8 bytes enciphered data En (OCV) has to be fed as input ICV to the next 
Decipher call. This is being managed by CFAP. For example: If the number of 8 byte blocks =10,000 and n max =4000, 
40 then Decipher instruction will be invoked as follows: 

- Decipher n=4000 
Decipher n=4000 

- Decipher n=2000 

45 

C1 64 bit control vector for data key (KD1 ). 

Outputs: A Plain data, in a multiples of 8 byte blocks. 
The 8 byte blocks are A1 , A2,...An. 

50 

Description: The input data is decrypted via the CBC mode of DEA encryption. The multiples of 8 byte blocks are 
decrypted by this instruction until all n blocks are decrypted. 

The architecture defines only plain ICV input to the function. If encrypted ICV is required, the CV can be encrypted 
using a data key (KD2) using encipher instruction. Encrypted ICVs can be decrypted using decipher instruction. All the 
55 encrypted ICVs and OCV.='s are managed by the CFAP. 

Fig. 16 is a block diagram of this instruction. 



25 



EP0 354 774 B1 



- CC: 

1. successful operation 
- 2. C1 is invalid 

3. unsuccessful operation (error) 

Control Vector Checking 

-- 1 . Checking on C1 

— CV type = "data/compatibility" or "data/privacy" or "data/ANSI" 

— D usage bit = 1 

— reserved (48:63)x ' '0' 

GENMAC (GMAC1 

- Equation: e*KM.C1(KD2=1), [e*KM.C2(KD2)], ICV[e*KM.C3(OCV)], A, n, iCV-type, output-type, mac-enc t C1, [C2], 
[C3] === MAC (64 bit) or e*KM.C3(OCV) 

Inputs: 

e*KM.C1 (KD1 ) KD1 is a MAC generation key for single encrypting MAC, triple encrypted under KM with a control 
vector C1. 

e*KM.C2(KD2) KD2 is an optional MAC generation key for triple encrypting MAC, triple encrypted under KM with 
a control vector C2. 

This is an optional input required for triple encrypting mac output if mac-enc =1 . 
IC V ICV equal to zero is the default Initial Chaining Value, and is standard to CA architecture, ANSI X9. 9 and ANSI X9. 1 9. 

Non-zero plain ICV can also be used to be compatible with systems which require plain ICV input. Encrypted ICV 
input is not supported by CA as it was found that it does not provide any more security for the function. Encrypted 
intermediate ICVs are supported by CA. 

NOTE: Encrypted ICVs if required are managed by CFAP as described in the ICV/OCV Management" and "Software 
Interface." 

e*KM.C3(OCV) This is a 64 bit intermediate ICV encrypted under the master key with a special control vector C3. 

This is an optional input which must be provided if large blocks of data (/n) are used to generate MAC. Decrypting 
the ICV is done internal to the function. Intermediate OCV can not be shipped from the local node, as it is stored under 
the master key with a control vector in the form for local use only. 

A Data to be MAC'd, in multiples of 8 byte blocks (A1 , A2... An). 

n number of 8 byte blocks to be MAC'd. n should be as large as possible, however, this may be system dependent. 

ccA does not define any maximum limit on n. if large number of blocks have to be MAC'd then GMAC is invoked 
multiple number of times until all blocks are complete. For example: if n max is 4000 for the system, and the data to be 
MAC'S are 10,000 8 byte blocks, then GMAC is invoked as follows: 

- GMAC n=4000,output-type=1 ,iCV-type=0 

- GMAC n=4000,output-type=1 ,iCV-type=2 
-- GMAC n=2000,output-type=1 ,iCV-type=2 

NOTE: After each call of GMAC, the intermediate ICV e*KM.C3(OCV) must be fed back to next GMAC call as ICV 
input. The decryption of this intermediate ICV must be done internally in the CF 

iCV-type iCV-type indicates whether the ICV passed to the function is zero, plain, or intermediate. 

Intermediate ICV is triple encrypted under the master key with a control vector C3. Zero ICV is a default value. 
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- 0: zero ICV (default) 

- 1: plain ICV 

« 2: intermediate ICV (OCV) 

output-type indicates the stage of the mac generation process to the instruction. 

- 0: MAC output 

- 1 : Intermediate ICV output (OCV) 

mac-enc mac-enc indicates a single or triple encryption mac output 

0: single encrypting mac output 
~ 1 : triple encrypting mac output(ANSI 9.1 9 requirement) 

C1 ,C2,C3 64 bit control vectors for KD1 , KD2, and OCV respectively. 

C2 and C3 are optional inputs to the instruction, C2 must be input if mac-enc=t , and C3 must be input if iCV-type 
=2 or output-type=1. 

Outputs: 

MAC is a 64 bit output, resulted from the single encryption or triple encryption of the final input block 

of data, depending upon mac-enc parameter. This output is valid only if output-type=0. 

e*KM.C3(OCV) OCV is a 64 bit intermediate ICV triple encrypted under KM with control vector C3. This output 
is valid only if output-type=1 . MAC output and Intermediate OCV outputs both must not be output 
at the same time for security reasons. 

Description: The input data is encrypted with CBC mode of DEA encryption, and the final block of encrypted data 
is output. There are two modes, the single encryption mode and triple encryption mode. With the single encryption mode, 
a single key KD1 is used to create the MAC. In the triple encryption mode, the single encryption mode is employed with 
KD1 to create a MAC, except the MAC is then decrypted with KD2, and re-encrypted again with KD1 to produce the 
final 64 bit MAC. 

The instruction outputs 64 bit MAC, however, X9.9 specifies 32 bit MAC which is 32 left most bits of the 64 bit MAC 
output. CFAP has to extract the appropriate MAC bits from the 64 bit MAC output. 

ICV is zero as a standard and optionally can be a plain or intermediate ICV to GMAC instruction. If encrypted ICVs 
are required then CFAP must encrypt ICV under (KDS) and must pass a plain ICV to the GMAC instruction. The ANSI 
X9.9 MAC standard specifies a zero ICV for the first block and thus is defined here as a standard input. However, 
architecture provides plain and intermediate inputs to satisfy every possible need of MAC generation. 

If MAC generation is required for the blocks greater than n, intermediate ICV option must be used to generate MAC. 
This requirement provides additional security by not exposing intermediate ICVs in clear 

If the data block is not multiples of 8 byte blocks, padding must be done. The padding has to be performed by the 
CFAP before invoking this function. MAC computation must be for the binary data as specified by the ANSI X9.9-1986 
section 5.0 and Coded character sets authentication if needed must be implemented by CFAP 

Fig. 17 is a block diagram of this instruction. 

- CC: 

« 1 . successful operation 
-- 2. C1 is invalid 

- 3. C2 or C3 is invalid 

« 4. unsuccessful operation (error). 

Control Vector Checking: 

— 1 . Checking on C1 

— data-type = "data/compatibility" or "data/mac" or "data/ANSI" 
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— MG usage bit = 1 

— reserved (48:63)=X l 0' 

- 2. Checking on C2 if (mac-enc =1). 

— CV type = "data/compatibility" or "data/mac" or "data/ANSI" 

— MG usage bit = 1 

— reserved 48:63) =X'0' 

- 3, Checking on C3 if (iCV-type=2 OR output-type =1 ). 

— CV type = "Intermediate ICV 
Verify MAC (VMAC) 

- Equation: e*KM.C1(KD1), [e*KM.C2(KD2)] ICV[e*KM.C3(OCV)], A, MAC, n, iCV-type, output-type, mac-enc, 
mac-len, C1, [C2], [C3] — == yes/no or e*KM.C3(OCV) 

Inputs: 

e*KM.C1(KD1) KD1 is a mac verification key for single encrypting mac, triple encrypted under KM with a control 
vector C1. 

e*KM.C2(KD2) KD2 is a mac verification key for triple encrypting mac, triple encrypted under KM with a control 
vector C2. 

This is an optional input required for triple encrypting mac output if mac-enc=1. 

ICV ICV equal to zero is the default Initial Chaining Value, and is standard to CA architecture, ANSI X9.9 and ANSI 
X9.19. 

Non-zero plain ICV can also be used to be compatible with systems which require plain ICV input. Encrypted ICV 
input is not supported by CA as it was found that it does not provide any more security for the function. Encrypted 
intermediate ICVs are supported by CA. 

NOTE: Encrypted ICVs if required are managed by CFAP as described in the "ICV/OCV Management" and 'Software 
Interface.' 

e*KM.C3(OCV) This is a 64 bit intermediate ICV encrypted under the master key with a special control vector C3. 

This is an optional input but must be provided if large blocks of data (] n) are used to verify MAC. Decrypting the 
ICV is done internal to the function. Intermediate OCV can not be shipped from the local node, as it is stored under the 
master key with a control vector in the form for local use only. The intermediate ICVs must be secret in the MAC veri- 
fication process to protect from attacks. 

A Data used in MAC, in multiples of 8 byte blocks (AT,A2...An). 
MAC 64 bit MAC input to the instruction either single or triple encrypted. 

By default, only left most 32 bits of this MAC are used for MAC comparison, mac-len may be used to explicitly 
specify other comparison lengths. 

n number of 8 byte blocks MAC'ed. n should be as large as possible, however, this may be system dependent. 

If large number of blocks have to be mac verified then VMAC is invoked multiple number of times until all blocks 
are complete. For example: if n max is 4000 for the system, and the data to be verified are 10,000 8 byte blocks, then 
VMAC is invoked as follows: 

NOTE: After each call of VMAC, the intermediate ICV e*KM.C3(OCV) must be fed back to next VMAC call as ICV 
input. The decryption of this intermediate ICV must be done internally in the CF. 

- VMAC n=4000,output-type=1 ,iCV-type=0 

- VMAC n=4000,output-type=1 ,iCV-type=2 
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-- VMAC n=2000,output-type=0,iCV-type=2 

iCV-type iCV-type indicates whether the ICV passed to the function is zero, plain, or intermediate. Intermediate 
ICV is triple encrypted under the master key with a control vector C3. 

— 0:zero ICV (default) 

— 1 plain ICV 

— 2:intermediate ICV (OCV) 

output-type indicates the stage of the mac verification process to the instruction 

— 0 : MAC Verification output 

— 1 : Intermediate ICV output (OCV) 

mac-enc mac-enc indicates a single or triple encryption mac input. 

— 0 : single encrypting mac input 

— 1 : triple encrypting mac input (ANSI 9.19 requirement) 

mac-len mac-len specifies the number of bytes of the mac to be compared. 4 left most bytes are compared 
as a default. 

— 0:4 left most bytes 

— 1:5 left most bytes 

— 2:6 left most bytes 

— 3:7 left most bytes 

— 4:8 bytes 

NOTE: provision of 4, 5, 6, 7, 8 byte MAC verification may subvert MAC generation process for 8 byte MAC. CFAP 
may consider some checking for different length MAC verification. 

C1 ,C2,C3 64 bit control vectors for KD1 , KD2, and CCV respectively. 

C2 and C3 are optional inputs to the instruction, C2 is required if mac-enc=1, and C3 is required if iCV-type=2 or 
output-type=1. 

Outputs: 

yes/no mac is verified or not. 

e*KM.C3(OCV) OCV is a 64 bit intermediate ICV triple encrypted under KM with control vector C3. This is an 
optional output valid for output-type=1 . 

Description: The input data is encrypted with CBC mode of DEA encryption using data key KD1 and 32 left most 
bits of the final encrypted block are compared for equality with the supplied MAC.32 bit MAC compare is a default value, 
and other comparisons must be made as specified by the mac-len parameter. CC = 1 is set for macs equal and CC=2 
is set rf macs are not equal. There are two encryption modes: single encryption mode, a single key KD1 is used to create 
the MAC. In the triple encryption mode, the single encryption mode is employed with KD1 to create a MAC, except the 
MAC is then decrypted with KD2, and re-encrypted again with KD1 to produce the final 64 bit MAC. The MAC is generated 
as specified by mac-enc input and then compared with the supplied mac to the function. 

The first ICV is zero as a standard and optionally can be plain. Intermediate ICV must be used if the mac'd data is 
greater than n blocks in length. If the data block is not multiples of 8 byte blocks, padding must be done. The padding 
has to be performed by the CFAP before invoking this instruction. 

Fig. 18 is a block diagram of this instruction. 

- CC: 

1. MACs equal 

2. MACs not equal 
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3. C1 is invalid 

4. C2 or C3 is invalid 

5. unsuccessful operation (error). 

Control Vector Checking: 
- 1 . Checking on C1 

— C V type = "data/compatibility" or "data/mac' or "data/ANSI" 

— MV usage bit = 1 

— reserved (48:63)=X'0' 

-- 2. Checking on C2 if (mac-enc =1 ). 

— CV type = "data/compatibility" or "data/mac" or "data/ANSI" 

— MG usage bit = 1 

— reserved 48:63) =X'0 l 

3. Checking on C3 if (iCV-type=2 OR output-type =1 ). 



— CVtype = "Intermediate ICV" 
Translate Cipher Text (TCTX~n 



- Equation: e*KM.C1 (KD1 ) f ICV1 , eKD1 (ICV1 ,A), e*KM.C2(KD2), ICV2, n, C1 , C2 
==== eKD2 (ICV2.A) 
Inputs: 



e*KM.C1 (KD1 ) KD1 is an input data key, triple encrypted under KM with a control vector C1 . 

ICV1 64 bit clear ICV. 

eKD1 (ICV1 ,A) KD2 is an output data key, triple encrypted under KM with a control vector C2 

ICV2 64 bit clear ICV. 

n Number of 8 byte blocks of data to be translated. 

C1 , C2 Control vectors for KD1 , KD2 respectively. 



- Outputs: eKD2(ICV2,A) outputs Data A encrypted with data key KD2 using ICV2. 

Description: Translate cipher text instruction translates data from one data key and ICV to another data key and 
ICV. This instruction operates with data/xlt keys, and data/compatibility keys. CV keys or CV=0 keys can be used to 
translate data, no mix and match of these key types are permitted by this instruction. The data can be up to n 8 byte 
blocks, the translation is done in the crypto facility without exposing the clear data outside the crypt facility. 

The ICV inputs ICV1 and ICV2 can only be plain ICV inputs to the instruction. No intermediate ICV is provided by 
the instruction. If more than n blocks of data have to be translated, and the data has to be chained then CFAP has to 
pass the last 8 byte encrypted block(En) as input to ICV If encrypted ICVs are used then CFAP must decipher the ICVs 
before passing ICVs to the instruction. 

NOTE: The xlate Ciphertext instruction is specifically designed to operate with CV-only keys (i.e., xlate data keys). 
There is no compatibility mode xlate ciphertext option offered. To get around this, the xlate ciphertext instruction will 
accept data keys with the D and E attributes as well as the XDin and XDout attributes. But this is provided as a service 
to reduce the accidental exposure of clear data, since an insider adversary could recover data unclear using the decipher 
instruction. It is not possible to isolate the xlate ciphertext keys in the compatibility mode, and to architect a control vector 
for this would give an illusion of security, when in fact, an attack could be perpetrated with the RTMK instruction by 
importing an intended xlate key (sent over CV=0 channel) as a decipher key. Thus, the xlate ciphertext data channel 
could be subverted by deciphering data sent over that channel. 

Fig. 19 is a block diagram of this instruction. 



- CC: 
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1. successful operation 
-- 2. C1 or C2 is invalid 
- 3. unsuccessful operation (error) 

Control Vector Checking: 

— 1. Checking on CI 

— CVy type ="data/xlt" or "data/compatability" 

— If (CV type = "data/xlt") then XDin = 1 

— reserved (48:63)=X0' 

2. Checking on C2 if (mac-enc =1). 

— CV type = "data/bet" or "data/compatability" 

— If (CV type ="data/xlt") then XDout = 1 . 

— reserved 48:63) =X'0' 

— 3. Checking on C1 and C2 

— CV type(C1 ) ="CV type (C2) 

MDCOP (MDC OPERATION) 

DESCRIPTION: It is within the skill of the art to provide an instruction which calculates a Modification Detection 
Code (MDC) and this is not further discussed herein. 

ICV/OCV Management 

An initial chaining value (ICV) is a 64 bit random, pseudo-random, or t in some cases, non-repeating value used with 
the cipher block chaining (CBC) mode of encryption of the DEA and with some algorithms for calculating message 
authentication codes (MACs). 

ICV management includes options for electronic transmission and local storage of both plain and encrypted ICVs. 
However, encrypted ICVs must first be decrypted before being used as input parameters to any of the cryptographic 
functions. 

An output chaining value (OCV) is a 64 bit value returned, under certain conditions, by the GENMAC and VERMAC 
cryptographic instructions. The same cryptographic instruction is again called and the OCV is passed as the ICV. The 
OCV is always encrypted in the form eKM.CV(OC V), where CV is a control vector for intermediate ICV For the VERMAC 
instruction, an encrypted OCV is absolutely essential for reasons of security. A plain OCV, in this case, could be used 
to reveal MACs, which is something that the VERMAC instruction is not supposed to do. An encrypted OCV is also 
defined for the GENMAC instruction. This is done so that the GENMAC and VERMAC instructions are made as similar 
as possible, thus allowing for possible function overlap in hardware. 

ICV Management Outside the Cryptroqraphic Facility 

The Communication Architecture permits the following three modes of electronic transmission of the ICV: 

1. Plain ICV: sent in the clear. 
- 2. Encrypted ICV: encrypted with a data key (KD) shared between the sender and receiver. 
3. Private Protocol: ICV established using a private protocol between sender and receiver. 

Under the CA t CFAP must handle both plain and encrypted ICVs. Although, applications may elect to manage their 
own encrypted ICVs thus passing plain ICVs to CFAP to encrypt ICVs for transmission and to decrypt all encrypted IDVs 
received from other nodes. Optionally the cryptographic support program may also establish ICVs using a private pro- 
tocol. 
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ICV Management Inside the Cryptographic Facility 

Control vectors are not used for the electronic distribution of IDVs, nor are there any bits in the control vector that 
may be used by the cryptographic facility (hardware) to control ICV distribution. There is no checking or enforcement 
s by the cryptographic facility of the mode of ICV distribution. Thus, ICV management is strictly a function of the crypto- 
graphic support program (i.e., software external to the cryptographic facility). 

AH ICV's passed as cryptographic function input parameters to the cryptographic facility must be plain ICVs. ICV = 
0, which is required by the GENMAC and VERMAC instructions, is just a subcase of Plain ICV. The affected cryptographic 
instructions are these: 

w 

1 . Encipher 

2. Decipher 

3. Genmac 
- 4. Vermac 

'5 - 5. Translate Cipher Text 

Acronyms and Abbreviations 



20 





CC 


Condition code 




CA or CCA 


Cryptographic Architecture 




CV 


Control Vector (nothing to do with ICV or OCV) 




CBC 


Cipher Block Chaining. An encryption mode of the Data Encryption Standard. 


25 


DED 


Decipher, Encipher and Decipher 




DEA 


Data Encryption Algorithm 




DES 


Data Encryption Standard 




ECB 


Electronic Code Book. An encryption mode of DES. 




EDE 


Encipher, Decipher and Encipher 


30 


ICV 


Input Chaining Value (Nothing to do with CV) 




KDx 


Data Key (x = integer) 




KEKx 


Key Encrypting Key (x = integer) 




KM 


Master Key 




KMN 


New master key 


35 


KMO 


Old master key 




KPEx 


Pin Encrypting Key (x = integer) 




KPGx 


Pin Generation Key (x = integer) 




KPVx 


Pin Validation Key (x = integer) 




KKNI 


Immediate notarized key, 1 28 bits 


40 


KKNIL 


Left 64 bits of KKNI 




KKNIR 


Right 64 bits of KKNI 




KDmac 


Temporary MAC key for ANSI message 




MAC 


Message Authentication Code 




MDC 


Modification Detection Code 
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OCV 


Output Chaining Value 




PIN 


Personal Identification Number (used with ATMs) 




Algorithms 




50 


Encode and Decode Algorithm 



The Encode and Decode instructions use the ECB (Electronic Code Book) mode of the DES. There is no chaining 
or feedback in this mode. Fig. 20 illustrates the operation of the ECB mode of encryption and decryption. 

55 Cipher Algorithm 

The Enciphering/Deciphering Algorithm is the National Bureau of Standards Data Encryption Standard (DES) or 
equivalents the American National Standards Institute Data Encryption Algorithm (ANSI DEA) X9.92-1 981 . Cipher Block 
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Chaining (CBC) is done as specified in ANSI Cryptographic Modes of Operation X9. 106-1 983. Figs. 21 and 22 show 
the CBC mode of operation of Encipher and Decipher operations respectively. 

Message Authentication (MAC) 

The Financial Institution Message Authentication Standard (Wholesale ANSI X9.9) as referenced in Reference (6), 
defines a process for authentication of messages from originator to recipient. This process is independent of commu- 
nication media an and payment systems. 

The authentication process includes the computation, transmission, and verification of a Message Authentication 
code (MAC). The MAS=C is based on either of the complete message text or a selected message elements of the text. 
The MAC is added to the message by the originator and is transmitted to the recipient. The message or message 
elements are accepted as authentic by the recipient if the same algorithm and secret key produce a MAC identical to 
the received MAC. The security of the authentication process is directly dependent on the security afforded to the secret 
key. 

The MAC is generated as shown in Fig. 23. The authentication algorithm as described in this standard may be 
implemented using either the 64 bit CBC or CFB modes of operation as described in ANSI X3. 106-1 983. Both modes 
shall be initialized so as to produce equivalent MAC'S. KEY is a 64 bit key, and A1 through An are 64 bit data blocks. 
Initial chaining value is '0' in this standard and CBC mode of operation should be implemented as shown in Fig. 23. If 
An is less than 64 bits, then '0*s are appended (padded) to the right of the remaining bits. The left most 32 bits of (on) 
are taken as the MAC. 

NOTE: The capability should exist to generate and to process 48 to 64 bit MAC'S. For these cases, the left most 48 
bits or the entire final output (On) are taken as the MAC. 

The algorithm describes the MAC generation for binary data. Message authentication for "Coded Character Sets" 
should be implemented as described in the ANSI X9.9-1986, the MAC algorithm is invoked after the characters are 
represented in binary data. 

MDC Algorithms 

Two MDC algorithms can be used: 

- 1 . MDC_2 - Two encipherments per 8 byte input data block 

- 2. MDC_4 - Four encipherments per 8 byte input data block 

Two different algorithms allow the invoker to trade a 50% performance improvement for a slight decrease in security 
depending on his applications. 

- MDC_2 (text) 

- 1 . Pad the input text with X'FP to a multiple of 8 bytes. 

- 2. Partition the input text into [n] 8 byte blocks T8[1 ] to T8[n]. 

- 3. If n=1 then set n=2 and T8[2] = 8 bytes of x'00'. 
4. Set initial values of KD1 and KD2 (see below). 

- 5. For[i] = 1,2,...,n: 

— a. MDCOP(KD1,KD2,T8[i],T8[i] 

— b. KD1 :=OUT1 

— c. KD2:=OUT2 

— d. end of FOR loop 

6. Output of MDC_2 is the 16 byte MDC :=(KD1 // KD2). 

- MDC_4 (text) 

1 . Pad the input text with X'FP' to a multiple of 8 bytes. 

- 2. Partition the input text into [n] 8 byte blocks T8[1 ] to T8[n] 

- 3. If n=1 then set n=2 and T8[2] = 8 bytes of xW 
4. Set initial values of KD1 and KD2 (see below) 

- 5. For[i] = 1 ( 2,...,n: 
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- a. MDCOP(KD1,KD2,T8[i]J8[i]) 

- b. KD1int:=OUT1 

- c. KD2int :=OUT2 

— d. MDCOP(KD1tnt,KD2int,KD2,KD1) 
s «- e. KD1 :=OUT1 

— LKD2:=OUT2 

— g. end of FOR loop 

- 6. Output of MDC_4 is the 16 byte MDC :=(KD1 // KD2) 

10 

The initial values of KD1 and KD2 are as follows: 

- 1. KD1 :=X , 5252525252525252' 

- 2. KD2 :=X'2525252525252525' 

15 

Notarisation Algorithms 
Using KK 

20 Let KK be the key which is to be used to compute the notarisation key. Then: 

KKR = KK + FM1 (+ is exclusive or operation, and FM1 is first 8 bytes of from ID) 

- KKL = KK + T01 (T01 is the first 8 bytes of to ID) 

- NS1 = eKKR(T02) (T02 is the second 8 bytes of to ID) 
25 - NSr = eKKL(FM2) (FM2 is the second 8 bytes of from I D) 

- NS = (left most 32 bits of NS1) // 

right most 32 bits of NSr) + CT 

(CT is a 64 bit counter associated with KK) 

- KN = KK + NS 

30 

KN is a notarised key used to encrypt either KD or KK. 
Using *KK 

35 Let *KK be the key which is to be used to compute the notarisation key. Then: 

- **KK = KK1 // KKr 

KKR = KKr + FM1 (+ is exclusive or operation, and FM1 is first 8 bytes of from ID) 

- KKL = KK1 + T01 (T01 is the first 8 bytes of to ID) 

40 - NS1 - eKKR(T02)+ CT (T02 is the second 8 bytes of to I D and CT is a 64 counter associated with *KK) 

- NSr = eKKL(FM2)+CT (FM2 is the second 8 bytes of from ID) 

- *KN = (KK1 + NS1 ) // (KKr + NSr) 

*KN is a notarised key used to encrypt either a KD or (*)KK. 

45 

Standards and Definitions 
Standards 

so ANSI X2.92 - 1 981 "Data Encryption Algorithm". 

ANSI X9.106 -1983 'Modes of PEA Operation'. 

ANSI X9.2 - 198X "Interchange Message Specification for Debit and Credit Card Message Exchange Among 
Financial Institutions', This standard specifies a common interface by which bank card originated messages relating 
to a financial transaction may be interchanged between private systems. It specifies message structure, format and 
ss content, data elements and values for data elements. 

ANSI X9.8 - 1982 "American National Standard for Personal Identification Number (PIN) Management and 
security'. This standard establishes standards and guidelines for the management and security of the Personal Iden- 
tification Number's (PIN's) life cycle. 
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ANSI X9.9 - 1986 'American National Standard for Financial Institution Message Authentication (Wholesale) ". 
This standard established a method to authenticate financial pessages (wholesale), including fund transfers (e.g. wire 
transfers), letters of credit, security transfers, loan agreements and foreign exchange contracts. 

NISI X9.17 - 1985 "Financial Institution Key Management (Wholesaled. This standard establishes methods (in- 
cluding the protocol) for the generation, exchange and use of cryptographic keys of authentication and encryption. 

ANSI X9.19 - 198X "Financial Institution Retail Message Authentication". This standard establishes a method to 
authenticate financial messages for retail transactions. 

ANSI X9.23 - 1 98X "Encryption of Wholes ale Financial Messages'. This standard established a method to encrypt 
wholesale financial messages in order to provide confidentiality (e.g., wire transfers, letters of credit, etc.) 

ISO DIS 8563 "Bank Card Origina ted Messages - Interchange Message Specifications - Content for Financial 
Transactions". This international standard specifies a common interface by which bank card originated messages re- 
lating to a financial transaction may be interchanged between private systems. It specifies message structure, format 
and content, data elements and values . 

ISO DIS 8720 "Message Authentication " 

ISO DP 8730 "Banking - Reguirements for Standard Message Authentication (wholesaler . This international 
standard specifies a technique for protecting the authenticity of messages passing between financial institutions by 
means of a Message Authentication Code (MAC). 

ISO DP 8731 'Banking - Approved Algorithms for Message Authentication - Part 1 : DES-1 Algorithm ". This part 
of ISO 8731 deals with the Data Encryption Algorithm (DEA-1) as a method for use in the calculation of the Message 
Authentication Code (MAC). Part-2 Other non DEA Algorithms 

ISO DP 8732 'Banking - K ey Management Wholesale " This international standard specifies methods for the man- 
gement of keying material used for the encryption and authentication of messages exchanged in the course of wholesale 
financial transactions. 

ISO DP 9546 "Personal Identification Number Management and Security Part 1 - PIN Protection Principles and 
Technique" This standard specifies the minimum security measures required for effective PIN management. Standard 
means of interchanging PIN data are provided. 

Instructions and Macros Summary Chart 

Fig. 24 summarises the equations for each of the data instructions. 

Operation 

The operation of the arrangement will become clear from the following description of the execution of several cryp- 
tograhic data management functions. These data management functions make use of the encipher, decipher, generate 
MAC, verify MAC and translate ciphertext instructions. Operationally, these instructions require, besides data, key and 
control vector parameters, an initial chaining value (ICV). However, since the ICV is of secondary importance in explaining 
the data management functions, as a convenience ICVs are omitted from the discussion. However, the reader will ap- 
preciate that the originator of ciphertext and MACs will also be required to generate, use, and communicate ICVs to 
other communicants in order that the cryptographic instruction will operate consistently and in conformance to their 
defined, architected interfaces. See for example C. H. Meyer and S. M. Matyas, "Cryptography: A New Dimension in 
Computer Data Security," John Wiley & Sons, 1982. 

- 1 . Data Confidentiality. Data confidentiality protects the contents of a message or file from unauthorised disclosure. 

Applications of data confidentiality include the following: 

- a. Session Protection. Data encryption is used to protect the confidentiality or session level data transmission be- 
tween two communicating devices. Each end user (device or application) shares a common data encrypting/de- 
crypting key, thus permitting each end user to both send and receive encrypted data. 

Under the disclosed arrangement, as shown in Fig. 25, session protection is provided by a data/privacy key shared 
between two end users. Each key is stored in operational form, i.e., encrypted under the master key of each respective 
device. The control vector usage attributes of each key are encipher (E) and decipher (D), respectively, which enables 
each key to be used to both encipher with an encipher instruction and decipher data with a decipher instruction. 

- b. File Protection. Data encryption to protect the confidentiality of data files. A single end user (device or application) 
possesses a data encrypting/decrypting key KD permitting data to be encrypted for storage and to be decrypted, 
at a later time, for purposes of recovery or access to the file. 
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Under the disclosed arrangement, as shown in Fig, 26, file protection is provided by a data/privacy key KD belonging 
to or possessed by a single end user. The key is stored in import form, i.e., encrypted under a key encrypting key with 
KEK/receiver attribute. The encrypted data/privacy key is stored in a data storage with the encrypted data, e.g., in a file 
header record. Because the key KD is encrypted under KEK in the import form, a re-encipher to master key (RTMK) 
instruction is authorised by the control vector for KEK to enable it to re-encipher the data/privacy key KD under the 
master key KM. Once in the operational form, the key KD can be used to encipher and decipher data. Storing the key 
KD in data storage encrypted under KEK in the import form means that the master key KM can be changed without 
causing the data/privacy key KD to be invalid or unusable for file recovery. The control vector usage attributes of the 
data/privacy key KD are encipher (E) and decipher (D). This permits a data file to be both encrypted using an encipher 
instruction and decrypted using a decipher instruction with the same key. 

c. Encrypted Mail Box. The encrypted mail box describes a multi-user environment in which each user has a da- 
ta/privacy key in two encrypted forms, encrypted under a storage key formed as the exclusive-OR of the master 
key KM and the control vector of the associated data/privacy key. The first form permits data encryption; the second 
form permits data decryption. The first form of the key is placed in a central directory or central registry accessible 
to all users of the system. Each so registered key is recorded under a user identifier belonging to the user who 
registers the key. Each sending user i can obtain a copy from the central directory. He then stores the encryption 
key under his master key KML The second form of the key is kept private by the receiving user j to which it belongs, 
under j's master key KMj. Thus, a user i who wishes to send encrypted messages to user j, first requests user j's 
encryption key from the public directory. Data encrypted by user i using an encipher instruction with this key is then 
sent to user j and placed in user j's mail box. User j can read received mail by decrypting first with his/her private 
decryption key using a decipher instruction. But since no other user has access to user j's decryption key, the 
environment is such that users can encrypt mail going to each other user but only the authorised designated receiving 
user can decrypt and read his/her mail. 

Under the disclosed arrangement, as shown in Fig. 27, an encrypted mail box environment is provided via a da- 
ta/privacy key which has been generated in two forms. The first form permits encipher (E) only and the second form 
permits decipher (D) (not necessarily decipher only, since possession of both encipher and decipher attributes by the 
recipient would suffice). The control vector usage attributes for the first form of the data/privacy key are encipher (E) 
only and for the second form of the key are decipher (D) only (or both E and D). 

- d. Ciphertext Translation Centre (CTC). The ciphertext translation centre is a network node or device capable of 
securely translating encrypted data from encryption under a first data key to encryption under a second data key 
with a translate ciphertext instruction. In effect, the CTC possesses one or more data keys under which encrypted 
data may be received and one or more data keys under which received encrypted data may be re-encrypted. These 
data keys thus establish a secure channel permitting the CTC to translate ciphertext from one key to another but 
not to decrypt ciphertext. The CTC may be further restricted from encrypting data with one or more of these da- 
ta/privacy keys for the purpose of introducing data into the secure channel. 

Under the disclosed arrangement, as shown in Fig. 28, a ciphertext translation centre is provided via a data/xlate 
key used in combination with a data/privacy key. Consider a network of n devices connected to a single ciphertext 
translation centre (CTC). Each device generates a data key in two encrypted forms. The first form is a data/privacy key 
stored in operational form, where the storage key is the master key KM exclusive-ORed with the control vector of the 
data/privacy key. The control vector for this key has encipher (E) and decipher (D) attributes for bi-directional commu- 
nication. The second form is a data/xlate key in export form, suitable for export to the CTC where the storage key is a 
key encrypting key KEK which is exclusive-ORed with the control vector of the data/xlate key. At the CTC, the received 
data/xlate key is imported using the RTMK instruction, which converts the received data/xlate key to an operational form. 
The control vector for this key has Xlate-in and Xlate-out attributes for bi-directional communication. Thus, data enci- 
phered at device T can be translated with a translate ciphertext instruction at the CTC to encipherment under a key 
known to any one of the other devices. But the CTC cannot decrypt received inbound encrypted data nor encrypt data 
in a form comparable to the outbound encrypted data, since the control vector associated with the data/xlate key has 
no usage attributes permitting the encipher or decipher instructions to be executed. 

In order to provide only uni-directional ciphertext translation from system A to system B, the respective control 
vectors establish that the first form of the first data key is a data/privacy key with an encipher only usage attribute; the 
second form of the first data key is a data/xlate key with an xlate-in usage attribute; the first form of the second data key 
is a data/privacy key with a decipher only (or encipher and decipher) usage attribute; and the second form of the second 
data key is a data/xlate key with an xlate-out usage attribute. 
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- e. Peer-to-Peer Ciphertext Translation. As is shown in Fig. 29, this environment consists of a chain of two or more 
CTCs which establish a secure channel from one set of network devices to another set of network devices. Fig. 29 
is an example of uni-directional peer-to-peer ciphertext translation. The first CTC in the chain possesses one or 
more data keys under which encrypted data may be received from the first set of network devices. Each CTC in the 
chain possesses one or more data keys under which encrypted data may be re-encrypted, but not decrypted. The 
CTCs may be further restricted from encrypting data with one or more of these keys for the purpose of introducing 
data into the secure channel. The last CTC in the chain re-encrypts the encrypted data under one or more data 
keys shared with members of the second set of network devices. 

Under the disclosed arrangement, a ciphertext translation centre is provided via a data/xlate key used in combination 
with either a data/privacy key or another data/xlate key. Consider a node i of a network A of devices connected to a 
node j of a network B of devices via a chain of k CTCs, labelled in order CTC1, CTC2,...,CTCk. Node i generates a data 
key in two forms. The first form is a data/privacy key in operational form. The control vector for this key has an E attribute. 
The second form is a data/xlate key in export form, suitable for export to CTC1 , the first CTC in the chain. At CTC1 , the 
received data/xlate key is imported using the RTMK instruction, which converts the received data/xlate key to an oper- 
ational form. The control vector for this key has an xlate-in attribute. 

Node j generates a key in the same two forms: an operational data/privacy key and exportable data/xlate key. The 
control vector of j's data/privacy key has a decipher attribute. The data/xlate key is shipped to CTCk, the last CTC in 
the chain. At CTCk, the received data/xlate key is imported to operational form via RTMK. The control vector for this 
key has an xlate-out attribute. 

Each CTC in the chain (except CTCk) generates a data/xlate key in two forms: operational and exportable. The 
operational data/xlate key has a control vector with an xlate-out attribute. The exportable form is shipped to the next 
CTC in the chain, i.e. CTCx ships to CTC(x+1 ) for x equals 1 to (k-1 ). The receiving CTC imports the received data/xlate 
key and converts it to operational form via the RTMK instruction. The control vector for the data/xlate key has an xlate-in 
attribute. 

Alternatively, a third party node can generate and ship a data/xlate key and its associated control vector in two forms 
for nodes x and x+1 , an xlateout for node x and an xlate-in for node x+1 . 

Thus, data enciphered at node i of network A with the encipher instruction, can be translated and re-translated along 
the chain of CTCs from CTC1 to CTCk with a translate ciphertext instruction and finally to node j of network B. But none 
of the CTCs in the chain can decrypt received inbound data nor encrypt arbitrary data in a form comparable to the 
outbound encrypted data Thus, the chain of CTCs and the above-defined keys form a secure channel permitting the 
CTCs, as a group to translate data enciphered under one key held by node i to encipherment under another key held 
by node j. Although Fig. 29 shows a uni-directional peer-to-peer communication, the control vectors can be modified to 
allow bi-directional communication. 

f. Translate Part of an Encrypted File. This is an application wherein part of an encrypted file can be translated to 
a key which can be conveniently shared with an intended receiver. The method avoids sharing the original data/pri- 
vacy key used to encrypt the file, since doing so may jeopardize the confidentiality of data not intended to be shared. 

In order for a user or application program to beneficially use this feature, it is necessary for the user to generate a 
data key in two encrypted forms. The first form of the data key is a data privacy key stored in operational form, i.e., 
encrypted under a storage key formed as the exclusive-OR operation of the master key and a first control vector asso- 
ciated with the first form of the data key. The second form of the data key is a data xlate key stored in import form., i.e., 
encrypted under a storage key formed as the exclusive-OR operation of a key encrypting key KEK1 and a second control 
vector associated with the second form of the data key, where the control vector of KEK1 defines KEK1 as an import 
key encrypting key 

NOTE: defining KEK1 as an import key encrypting key permits the so encrypted data xlate key encrypted under 
KEK1 to be re-enciphered, at any later time, from encipherment under KEK1 to encipherment under the master key via 
a re-encipher to master key (RTMK) instruction. 

The control vector for the first form of the data key is a data/privacy control vector with usage attribute encipher (E), 
thus allowing data to be enciphered under the data key via an encipher instruction. The control vector for the second 
form of the dat key is a data/xlate control vector with usage attribute xlate in (Xin), thus allowing data enciphered under 
the data key to be translated from encipherment under the data key to encipherment under some other data key via a 
translate ciphertext instruction. 

In practice, as shown in Fig. 30, the data file is first encrypted with the data key K1 via an encipher instruction using 
the first form of the data key, i.e., the operational form of the key whose control vector is a data/privacy control vector 
with usage attribute encipher (E). The second form of the data key stored in import form is written in a header record of 
the encrypted data file. Thus, at any later time when it is desired to translate part of the encrypted data file from encryption 



37 



EP 0 354 774 B1 



under the present data key (called the first data key) to encryption under a second data key, the following procedure is 
followed The second form of the first data key stored in import form and written in the header record of the encrypted 
data file is assessed and is re-enciphered from encryption under KEK1 to encryption under the master key by using an 
RTMK instruction. This converts the second form of the data key (i.e., the data/xlate with xin usage attribute) to an 
operational key which is now suitable for use in translate ciphertext instruction. 

A second data key K2 is now generated in two encrypted forms. The first encrypted form of the key is a data/xlate 
key stored in operational form, i.e., encrypted under a storage key formed as the exclusive-OR operation of the master 
key and the control vector associated with the data/xlate key. The second encrypted form of the key is a data/privacy 
key stored in export form, i.e., encrypted under a key encrypting key KEK2 shared with the intended receiver. (It is 
assumed that the intended receiver can import the so-generated data/privacy key via a re-encipher to master key (RTMK) 
instruction, thus causing the data/privacy key to be stored encrypted under a storage key formed as the exclusive-OR 
operation of the master key of the supporting device and the control-vector associated with the data/privacy key.) The 
control vector usage attributes for the first form of the second data key (i.e., for the data/xlate key) are xlate out (Xout) 
and for the second form of the second data key (i.e., for the data/privacy key) are decipher (D) only (or decipher and 
encipher). Now a portion of the encrypted data file is re-enciphered from encryption under the first data key to encryption 
under the second data key via a translate ciphertext instruction, using second encrypted form of the first data key which 
has been re-enciphered from import form to operational form (whose control vector designates the key as a data/xlate 
key with Xin usage attribute) and the first encrypted form of the second data key already in operational form (whose 
control vector designates the key as a data/xlate key with Xout usage attribute). The so-translated ciphertext is then 
sent from system i to the intended receiver system j, whereupon the encrypted data is decrypted via a decipher instruc- 
tion, using the second form of the second data key (whose control vector designates the key as a data/privacy key with 
a D usage attribute). 

As shown by the example, Part A' of the encrypted file A can be given to another user j without requiring the data 
to be decrypted in clear form at the device of the first user i and without requiring the first user i to share the data key 
Kt under which the entire file A is encrypted. 

- 2. Data Integrity. Data integrity protects the contents of a message or file from unauthorized modification. This 
includes changes, additions, and deletions to the data. Cryptography provides only methods for detecting unau- 
thorised changes to data. It cannot prevent unauthorised changes to data. 

Message Integrity. Each end user (device or application program) in a multi-user environment shares a common 
data MAC generation/verification key, thus permitting each end user to generate MACs (message authentication 
codes) on messages transmitted to any other end user and permitting each end user to verify MACs on mes- 
sages received from other end users. 

Under the disclosed arrangement, as shown in Fig. 31, message integrity is provided by a data/MAC key shared 
between two end users. Each key is stored in operational form, i.e., encrypted under a storage key formed as the 
exclusive-OR operation of the master key of the device serving each respective end user and the control vector asso- 
ciated with the data/MAC key. The control vector usage attributes of each key are MAC generation (MG) and MAC 
verification (MV), respectively, which permits each user's key to be used for both MAC generation and MAC verification. 
Thus, the integrity of messages communicated between the respective end users can be assured. Thus, for example, 
the first end user generates a MAC on a message to be sent to the second end user via a generate MAC instruction, 
using his copy of the data/MAC key The message and MAC are then communicated to the second end user. The second 
end user verifies the MAC via a verify MAC instruction, using his copy of the data/MAC key. Since the control vectors 
for each copy of the key have usage attributes MG and MV, each user can generate and verify MACs with the key, and 
messages and MACs can be communicated from the first user to the second user or the second user to the first user. 

Message Integrity with Non-Repudiation. Each end user (device or application program) in a multi-user environment 
has a data/MAC key in two encrypted forms, i.e., encrypted under a storage key formed as the exclusive-OR oper- 
ation of the respective device master key and the respective control vector associated with the data/MAC key. The 
first form permits MAC verification; the second form permits MAC generation. The first form of the key is placed in 
a public directory or central registry accessible to all users of the system. Each so registered key is recorded under 
a user identifier belonging to the user who registers the key. The second form of the key is kept private by the user 
to which it belongs. Thus, a user j who wishes to send a message and MAC to user i, generates a MAC on the 
desired message via a GENMAC instruction using the private MAC generation key belonging to user j. The message 
and MAC are then communicated to user i. To verify the received message and MAC, user i first requests user j's 
MAC verification key from the public directory. (Note: if the public directory is located at a device different from the 
device supporting user i, then it is necessary to export and import the desired key using an RFMK and an RTMK 
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instruction. This causes the MAC verification key to be re-enciphered under a key encrypting key shared between 
the two devices, via an RFMK instruction, for purposes of exporting the key and then to be re-enciphered under the 
master key at the device supporting user i via an RTMK instruction.) User i then verifies the received message and 
MAC via a verify MAC instruction using j's MAC verification key. But since no other user has access to user j's MAC 
generation key, the environment is such that users can verify MACs and messages received from any other user 
(say user v) but cannot generate MACs on messages using any other user's MAC generation key. Thus one user 
cannot pose as another user and generate MACs with another user's MAC generation key. Conversely, a user (say 
user j) cannot deny or repudiate a valid massage and MAC as having originated with that user if the message and 
MAC is successfully verified with that user's MAC verification key via the verify MAC instruction. This is called 
non-repudiation. 

Under the disclosed arrangement, as shown in Fig. 32, message integrity with non-repudiation is provided via a 
data/MAC key which has been generated in two encrypted forms. The first form permits MAC verification only and the 
second form permits MAC generation (not necessarily MAC generation only, since possession of both MAC generation 
and MAC verification would suffice). The control vector usage attributes for the first form of the data/MAC key are MAC 
verification (MV) only and for the second form of the key are MAC generation (MG) only (or both MG and MV). 

3. Message Authentication. Message authentication is a procedure established between two communicants which 
allows each communicant to verify that received messages are genuine. Communicants can be people, devices, 
or processing functions. Message authentication allows the receiver of a message to determine that 

The message originated with the alleged sender. 

The contents of the message have not been accidentally or intentionally changed. 
- The message has been received in the same sequence that it was transmitted. 
-- The message was delivered to the intended receiver. 

As can be seen, message authentication encompasses a requirement for message integrity, but is a broader con- 
cept. Message authentication, as defined here, permits the receiver to additionally validate a message's origin, timeliness 
or sequence, and intended destination. To accomplish these additional features, a sender identifier field, a receiver 
identifier field, and a sequence number field are included in each message, as shown in Fig. 33. Thus, upon receipt of 
a message and MAC, the contents of the message are first authenticated via the MAC using a verify MAC instruction 
and a MAC verification key shared between the two users (i.e., which has been previously established via the key 
management processes). Once the contents of the message have been authenticated, a simple check is performed to 
verify that the sender identifier is equal to the identifier of the MAC verification key belonging to the anticipated or intended 
sender of the message, that the value in the sequence number field is one greater than the sequence number in the 
previously received message from that same sender, and that the receiver identifier is equal to the identifier of the actual 
receiver. If all checking is passed successfully, the received message is accepted as valid; otherwise the message is 
rejected. Message authentication and message authentication with non-repudiation are achieved in the same way the 
data integrity and data integrity with non-repudiation are achieved (see the applications described under items 2a and 
2b, respectively), except that additional fields are defined and checked in the message as just outlined. 

In an alternative embodiment of the invention, clear keys can be stored in the crypto facility for immediate availability 
in cryptographic operations. Those clear keys can be stored for example in the working storage 24 in Fig. 1 of the crypto 
facility 4 or alternately they can be stored in the working key registers of the crypto facility as in shown in Fig. 2. 

In a first method, each key and its associated control vector are stored as a paired expression in the RAM within 
the crypto facility. Each such key and control vector are initialised within the crypto facility, in advance of their intended 
use, via a special authorised procedure available only to authorised system personnel (e.g., a security officer). A pro- 
cedure similar to initialising a master key (e.g., via a hand-held key entry device attached to a front panel interface, 
which is enabled via a physical key-activated key switch) could easily be adapted for initialising keys and control vectors 
within the crypto facility. Methods for initialising parameters within the crypto facility are well-known in the art. During 
routine operations, in order to access a particular key, the associated control vector is first accessed and the control 
vector checking operation is carried out as has been previously described, in order to ensure that the proposed key 
usage is authorised. If the authorisation is affirmative, then the corresponding key is accessed from the RAM and is 
used for the intended operations within the crypto facility. 

In a second method, the exclusive-OR product of the key and its associated control vector are stored in the RAM 
inside the crypto facility, i.e., instead of store the key and control vector paired expression (as with the first method) the 
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key and control vector are exclusive-ORed and the product of the exclusive-OR operation is stored in the RAM inside 
the crypto facility. A procedure for initialising the crypto facility could be based on performing the exclusive-OR operation 
of the key and control vector outside the crypto facility and then entering their product as a parameter using a procedure 
similar to that for entering the key and control vector, as described for the first method. Alternatively, the key and control 
vector could be exclusive-ORed within the crypto facility and the product then stored as before. Later on, the steps to 
access a key can be traced as follows. An instruction which designates the use of a particular key must'also provide 
the control vector associated with that key as a parameter of the instruction. The control vector is first checked, as before, 
using the control vector checking operation, in order to ensure that the proposed key usage is authorised. If the author- 
isation is affirmative, the exclusive-OR product of the key and control vector stored in the crypto facility is accessed and 
exclusive-ORed with the control vector supplied as a parameter to the instruction to recover the clear key which is then 
used in the intended crytographic operations. It can be seen that if cheating is attempted, i.e., a false control vector is 
specified in an instruction, then the clear value of the recovered key is not correct (i. e., is not the correct key value). The 
crypto instructions are designed such that no useful outputs are obtained when an incorrect key value is produced as 
a result of such control vector cheating. 



Claims 

1. A method for validating that data cryptography functions requested for a cryptographic key have been authorised 
by the originator of the key in a data processing system which processes cryptographic service requests for the 
performance of data cryptography functions on data using cryptographic keys which are associated with control 
vectors defining the functions which each key is allowed by its originator to perform, comprising the steps of: 

receiving a cryptographic service request for performing a data cryptography function on data using a crypto- 
graphic key in a cryptographic facility (4) having a secure boundary (6) through which passes an input path and 
an output path (8); 

receiving a control vector (fig. 5) associated with the cryptographic key and checking (1 4) that the control vector 
authorises the data cryptography function which is requested by the cryptographic service request; and 

signalling (20) that the data cryptography function is authorised and initiating the performance of the requested 
data cryptography function with the cryptographic key. 

2. A method as claimed in claim 1 , which further comprises storing in a storage means (22) the cryptographic key in 
an encrypted form in which the cryptographic key is encrypted under a storage key which is a logical product of the 
associated control vector and a master key (18). 

3. A method as claimed in claim 2, wherein the storage key is the exclusive-OR product of the associated control 
vector and the master key stored in the master key storage. 

4. A method as claimed in any preceding claim, wherein the associated control vector is stored with the encrypted 
form of the cryptographic key in the cryptographic key storage means. 

5. A method as claimed in any preceding claim , wherein the associated control vector includes fields defining author- 
ised types of cryptographic functions including key management functions, data cryptography functions and PIN 
processing functions, and the data cryptography functions type is designated. 

6. A method as claimed in any preceding claim, wherein the associated control vector includes fields defining export 
control and usage. 

7. A method as claimed in claim 6, wherein the associated control vector further includes a usage field designating 
one of the following - 

- that the cryptographic key can perform encryption of the data; 
that the cryptographic key cannot perform encryption of the data; 
that the cryptographic key can perform decryption of the data; 
that the cryptographic key cannot perform decryption of the data; 
that the cryptographic key can perform data cryptography functions; 
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- that the cryptographic key can perform message authentication functions; 

- that the cryptographic key can be used to generate a message authentication code on the data; 
that the cryptographic key cannot be used to generate a message authentication code on the data; 
that the cryptographic key can be used to verify a message authentication code on the data; 

- that the cryptographic key cannot be used to verify a message authentication code on the data; 

- that the cryptographic key cannot be used as the output data key in a translate ciphertext function; 

- that the cryptographic key can be used as the input data key in a translate ciphertext function 

- that the cryptographic key cannot be used as the input data key in a translate ciphertext function. 

- that the cryptographic key can perform data cryptography functions and further includes a subtype field desig- 
nating that the cryptographic key is an ANSI data key. 

8. A method as claimed in claim 6, wherein the associated control vector includes a type field designating that the 
cryptographic key can perform data cryptography functions and further includes an export control field which des- 
ignates whether the local data processing system is allowed to export the cryptographic key and further designates 
whether a remote data processing system to which the local data processing system is connected, is allowed to 
re-export the cryptographic key. 

9. A method as claimed in claim 6, wherein the associated control vector includes a type field designating that the 
cryptographic key can perform data cryptography functions and further includes a subtype field designating that the 
cryptographic key can perform data privacy functions. 

10. A method as claimed in claim 9, wherein the associated control vector includes a type field designating that the 
cryptographic key can perform data cryptography functions and further includes a subtype field designating that a 
translate ciphertext function can be performed by the cryptographic key. 

11. A method as claimed in claim 10, wherein the associated control vector further includes a usage field designating 
that the cryptographic key can be used as the output data key in a translate ciphertext function. 

12. A method as claimed in claim 9, wherein the data cryptography function is session protection to protect the confi- 
dentiality of data transmissions between two communicating devices in the system which share a common data 
encrypting/decrypting key, permitting each device to both send and receive encrypted data, comprising the steps of: 

sharing a data privacy key between the devices; 

storing the data privacy key in operational form encrypted under a master key at each respective device; 

providing usage attributes for the control vector of each data privacy key for enciphering and deciphering, 
respectively, which enables each key to be used to both encipher and decipher data. 

1 3. A method as claimed in claim 1 2, wherein the data cryptography function is file protection to protect the confidentiality 
of data files, wherein a single end user possesses a data encrypting/decrypting key permitting data to be encrypted 
for storage and to be decrypted for purposes of recovery of the file, further comprising the steps of: 

providing a data privacy key to the single end user; 

storing an encrypted form of the data privacy key with data which has been encrypted thereby; 

the data privacy key being stored in import form encrypted under a key encrypting key, with its associated 
control vector, 

providing usage attributes for the control vector of the data privacy key for enciphering and deciphering, thereby 
permitting the data file to be both encrypted and decrypted with the same key. 

14. A method as claimed in claim 12, wherein the data cryptography function is an encrypted mail box in which each 
user of a plurality of users of the system has a data privacy key in two forms, the first form permitting data encryption 
and a second form permitting data decryption, the first form of the key being placed in the public directory accessible 
to all users of the mail box so that each registered key is recorded under one user identifier belonging to the user 
who registers the key, the second form of the key being private to the user to which it belongs, so that mail deposited 
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in the mail box directed to a particular user in its encrypted form, can be decrypted only by that user - the intended 
recipient - comprising the steps of: 

providing a data privacy key which has been generated in two forms, the first form permitting enciphering only 
s and the second form permitting deciphering; 

providing control vector usage attributes for the control vector associated with the data privacy key, which has 
for the first form of the data privacy key encipher only features and which has for the second form of the data 
privacy key decipher features. 

70 

15. A method as claimed in claim 12, wherein the data cryptography function is a ciphertext translation function to be 
performed at a ciphertext translation centre in a network in the system capable of securely translating encrypted 
data from encryption under a first data key to encryption under a second data key, comprising the steps of: 

15 generating a data key in two forms at a plurality of devices in the communications network, the first form being 

a data privacy key in operational form having an associated control vector which has encipher and decipher 
attributes, and a second form of the data key being a data translate key in the export form, suitable for export 
to a ciphertext translation centre in the network; 

20 receiving the data translate key at the ciphertext translation centre and converting the received data translation 

key to an operational form, the control vector associated with the data translation key having both translate-in 
and translate-out attributes; 

enciphering data at some first device which is transmitted to the ciphertext translation centre where it is trans- 
25 lated to encipherment under the second data key known to some second device in the network connected to 

the ciphertext translation centre; 

transmitting the translated data from the centre to the second device where it is deciphered under the second 
data key. 

30 

16. A method as claimed in claim 15, wherein the ciphertext translation center cannot decrypt received inbound 
encrypted data nor can it encrypt data in a form comparable to outbound encrypted data. 

17. A method as claimed in claim 1 2, wherein the data cryptography function is a peer-to-peer ciphertext translation for 
35 a communications network chain in the system which includes a first device which originates a communication, 

connected to a first ciphertext translation centre which in turn is connected to a second ciphertext translation centre 
which in turn is connected to a second network device, for a transmission of encrypted data from the first device 
through the first and second ciphertext translation centres to the second device, comprising the steps of: 

40 generating a first data key in the first network device in two forms, the first form being a data privacy key in 

operational form having an associated control vector which has encipher attributes, and a second form of the 
first data key being a data translate-in key in the export form, suitable for export to the first ciphertext translation 
centre; 

45 generating a second data key in the second network device in two forms, the first form being a data privacy 

key in operational form having an associated control vector which has decipher attributes, and a second form 
of the second data key being a data translate-out key in export form, suitable for export to the second ciphertext 
translation centre; 

50 generating a third data key in the first ciphertext translation centre in two forms, the first form being a data 

translate-out key and the second form being a data translate-in key, suitable for export to the second ciphertext 
translation centre; 

the first network device transmitting the first data key in its second form as a translate-in key to the first ciphertext 
55 translation centre; 

the second network device transmitting the second data key in its second form as a translate-out key to the 
second ciphertext translation centre; 
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the first ciphertext translation centre transmitting the third data key in its second form as a translate-in key to 
the second ciphertext translation centre; 

the first network device encrypting data under the first data key in the first form and transmitting the encrypted 
data to the first ciphertext translation centre where the data is translated under the first data key in the second 
form to be encrypted under the third data key in the first form to be translated out and transmitted to the second 
ciphertext translation centre where the data is translated under the third data key in its second form into a form 
encrypted under the second data key in the second form where it is translated out and transmitted to the second 
network device where the data is then decrypted under the second data key in its first form. 

1 8. A method as claimed in claim 1 2, wherein the data cryptography function is applied to an encrypted file under a first 
key so that a portion of the file can be re-encrypted under a second key for transmission to an intended receiver, 
without revealing the entire encrypted file, comprising the steps of: 

generating a first data key in two forms at a first device in the system, the first form being a data privacy key 
stored in operational form and the second form being a data translate-in key; 

encrypting a data file using the data privacy key and storing the file in its encrypted form in a data storage device; 

the first device generating a second data key in two forms, a translate-out key and a data decryption key; 

transmitting the data decryption key to a second device in the system connected to the first device; 

accessing the data file from the data storage device and re-enciphering a portion of the file from encipherment 
under the first data key to encipherment under the second data key via a translate ciphertext instruction using 
the first data key in the translate-in form and the second data key in the translate-out form and transmitting the 
re-enciphered portion of the data file from the first device to the second device; 

decrypting the transmitted portion of the data file by means of the decryption key form of the second key for 
use at the second device. 

19. A method as claimed in claim 1 2, wherein the data cryptography function is message integrity, wherein the contents 
of a message is protected from unauthorised modification, comprising the steps of: 

providing a data/MAC key and an associated control vector having MAC generation and MAC verification 
attributes at both a sending station and a receiving station in a communications network in the system; 

computing an MAC value for a message to be sent from the sending station to the receiving station, employing 
the data/MAC key and the control vector at the sending station; 

transmitting the message and the computed MAC value from the sending station to the receiving station; 

computing a second value on the received message at the receiving station, employing the data/MAC key and 
the control vector and comparing the second computed MAC value with the transmitted MAC value; 

verifying the integrity of the message received at the receiving station when the two computed MAC values are 
equaJ. 

20. A method as claimed in claim 1 2, wherein the data cryptography function is message authentication with non-repu- 
diation, comprising the steps of: 

providing a data/MAC key with a first associated control vector having an MAC generation attribute at a sending 
station in a communications network in the system; 

providing the data/MAC key with a second control vector having an MAC verification attribute but not having 
an MAC generation attribute, at a receiving station in the communications network; 

computing a first value for the MAC on a message to be sent by the sending station over the communications 
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network to the receiving station, using the the data/MAC key and the first control vector at the sending station; 

transmitting the message and the first MAC value from the sending station over the communications network 
to the receiving station; 

computing a second value for the MAC on the message received at the receiving station, using the data/MAC 
key and the second control vector, at the receiving station; 

verifying that the message has integrity and that it was sent by the sending station, when the first value for the 
MAC equals the second value for the MAC. 

21. A method as claimed in claim 12, wherein the data cryptography function is a peer-to-peer ciphertext translation for 
a communications network chain in the system which includes a key issuing device in the network, a first device 
which originates a communication, connected to a first ciphertext translation centre which in turn is connected to a 
second ciphertext translation centre which in turn is connected to a second network device, for a transmission of 
encrypted data from the first device through the first and second ciphertext translation centres to the second device, 
comprising the steps of: 

generating a first data key in the first network device in two forms, the first form being a data privacy key in 
operational form having an associated control vector which has encipher attributes, and a second form of the 
first data key being a data translate-in key in the export form, suitable for export to the first ciphertext translation 
centre; 

generating a second data key in the second network device in two forms, the first form being a data privacy 
key in operational form having an associated control vector which has decipher attributes, and a second form 
of the second data key being a data translate-out key in export form, suitable for export to the second ciphertext 
translation centre; 

generating a third data key in the key issuing device in two forms, the first form being a data translate-out key 
suitable for export to the first ciphertext translation centre and the second form being a data translate-in key, 
suitable for export to the second ciphertext translation centre; 

the first network device transmitting the first data key in its second form as a translate-in key to the first ciphertext 
translation centre; 

the second network device transmitting the second data key in its second form as a translate-out key to the 
second ciphertext translation centre; 

the first key issuing device transmitting the third data key in its first form as a translate-out key to the first 
ciphertext translation centre and transmitting the third data key in its second form as a translate-in key to the 
second ciphertext translation centre; 

the first network device encrypting data under the first data key in its first form and transmitting the encrypted 
data to the first ciphertext translation centre where the data is translated under the first data key in the second 
form to be encrypted under the third data key in the first form to be translated out and transmitted to the second 
ciphertext translation centre where the data is translated under the third data key in the second form into a form 
encrypted under the second data key in the second form where it is translated out and transmitted to the second 
network device where the data is then decrypted under the second data key in the first form. 

22. A data processing system which processes cryptographic service requests for performing data cryptography func- 
tions on data using cryptographic keys which are associated with control vectors defining the functions which each 
key is allowed by its originator to perform, comprising: 

a cryptographic facility (4) having a secure boundary (6) through which passes an input path (8) for receiving 
the cryptographic service requests, data, cryptographic keys and their associated control vectors, and an output 
path (8) for providing responses thereto, there being included within the boundary (6) a cryptographic instruction 
storage (10) coupled to the input path, a control vector checking means (14) and a cryptographic processing 
means (1 6) coupled to the instruction storage, and a master key storage (1 8) coupled to the processing means 
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(16), for providing a secure location for executing data cryptography functions in response to the received 
service requests; 

the cryptographic instruction storage (10) receiving over the input path (8) a cryptographic service request for 
performing a data cryptography function with a cryptographic key; 

the control vector checking means (14) having an input coupled to the input path (8) for receiving a control 
vector (figure 5) associated with the cryptographic key and an input coupled to the cryptographic instruction 
storage (10), for receiving control signals to initiate checking that the control vector authorises the data cryp- 
tography function which is requested by the cryptographic service request; 

the control vector checking means (14) having an authorisation output (20) coupled to an input of the crypto- 
graphic processing means (16), for signalling that the data cryptography function is authorised, the receipt of 
which by the cryptographic processing means (16) initiates the performance of the requested data cryptography 
function with the cryptographic key. 



Patentanspruche 

1. Ein Verfahren zur Validierung der Tatsache, daft Datenkryptographiefunktionen, die fur eine Kryptographieschlus- 
selfunktion benotigt werden, vom Betatiger der Schlusselfunktion in einem Datenverarbeitungssystem autorisiert 
wurden, das Kryptographieanforderungen zur Durchfuhrung von Datenkryptographiefunktionen unter Verwendung 
von Kryptographieschlusselfunktionen verarbeitet, die eine Zuordnung zu Steuervektoren besitzen, die die Funk- 
tionen definieren, die der Betatiger fOr jede Schlusselfunktion wunscht, bestehend aus folgenden Schritten: 

Empfang einer Kryptographieanforderung zur Durchfuhrung einer Datenkryptographiefunktion unter Vewen- 
dung einer Kryptographieschlusselfunktion in einer Kryptographieeinrichtung (4), die eine sichere Begrenzung 
(6) besitzt, durch die ein Eingabepfad und ein Ausgabepfad (8) lauft; 

Empfang eines Steuervektors (Figur 5), der der Kryptographieschlusselfunktion zugeordnet ist und Sicherste!- 
lung (14), daG der Steuervektor die Datenkryptographiefunktion autorisiert, die von der Kryptographieanforde- 
rung angefordert wurde; und 

Signalisierung (20), daG die Datenkryptographiefunktion autorisiert ist Einleitung der Ausf uhrung der angefor- 
derten Datenkryptographiefunktion mitder Kryptographieschlusselfunktion. 

2. Ein Verfahren gemaG Anspruch 1 , das weiterhin die Speicherung der Kryptographieschlusselfunktion in einer kodier- 
ter Form, in der die Kryptographieschlusselfunktion unter einer Speicherschlusselfunktion, die ein logisches Produkt 
des zugeordneten Steuervektors und einer Masterschiusselfunktion (18) ist, kodiert ist, in einem Speichermittel 
(22) umfaGt. 

3. Ein Verfahren gemaG Anspruch 2, bei dem die Speicherschlusselfunktion das Exklusiv-ODER-Produkt des zuge- 
ordneten Steuervektors und der im Masterschlusselfunktions-speicher gespeicherten Masterschiusselfunktion ist. 

4. Ein Verfahren gemaG alien vorherigen Anspruchen, bei dem der zugeordnete Steuervektor mit der kodierten Form 
der Kryptographieschlusselfunktion im Kryptographiespeichermittel gespeichert ist. 

5. Ein Verfahren gemaG alien vorherigen Anspruchen, bei dem der zugeordnete Steuervektor Felder, in denen die 
autorisierten Kryptographiefunktionstypen sowiedie Schlusselmanagementfunktionen, Datenkryptographiefunktio- 
nen und PIN-Verarbeitungsf unktionen definiert sind, und eine Angabe des Datenkryptographiefunktionstyps enthalt. 

6. Ein Verfahren gemaG alien vorherigen Anspruchen, bei dem der zugeordnete Steuervektor Felder enthatt, in denen 
die Ausgabesteuerung und -verwendung definiert ist. 

7. Ein Verfahren gemaG Anspruch 6, bei dem der zugeordnete Steuervektor weiterhin ein Verwendungsfeld umfaGt, 
in dem eine der folgenden Angaben bezeichnet ist: 

daG die Kryptographieschlusselfunktion eine Datenkodierung durchfuhren kann; 
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- daB die KryptographieschlGsselfunktion keine Datenkodierung durchfuhren kann; 

- daB die KryptographieschlGsselfunktion eine Datendekodierung durchfuhren kann; 
daB die Kryptographieschlusseifunktion keine Datendekodierung durchfOhren kann; 

- da3 die KryptographieschlGsselfunktion Meldungsauthentizitatsfunktbnen durchfuhren kann; 

- daB die Kryptographieschlusseifunktion verwendet werden kann, um auf den Daten einen Meldungsauthenti- 
zitatskode zu erzeugen; 

daB die KryptographieschlGsselfunktion nicht verwendet werden kann, um auf den Daten einen Meldungsau- 
thentizitatskode zu erzeugen; 

- daB die Kryptographieschlusseifunktion verwendet werden kann, um auf den Daten einen Meldungsauthenti- 
zitatskode zu Gberprufen; 

- daB die KryptographieschlGsselfunktion nicht verwendet werden kann, um auf den Daten einen Meldungsau- 
thentizitatskode zu Gberprufen; 

- daB die Kryptographieschlusseifunktion nicht als Ausgabedatenschlusselfunktion in einer Verschlusselungs- 
textaufldsungsfunktion verwendet werden kann; 

- daB die KryptographieschlGsselfunktion als Eingabedatenschlusselfunktion in einer VerschlGsselungstextauf- 
losungsfunktion verwendet werden kann; 

- daB die KryptographieschlGsselfunktion nicht als Eingabedatenschlusselfunktion in einer VerschlGsselungs- 
textauflosungsfunktion verwendet werden kann; 

daB die Kiyptographieschlusserfunktion Datenkryptographiefunktionen ausf Ghren kann und werterhin ein Sub- 
feld umfaBt, in dem angegeben ist, daB die Kryptographieschlusseifunktion eine ANSI-Datenschlusselfunktion 
ist. 

Ein Verfahren gemaB Anspruch 6, bei dem der zugeordnete Steuervektor ein Typenfeld umfaBt, in dem angegeben 
ist, daB die Kryptographieschlusseifunktion Datenkryptographiefunktionen ausfGhren kann und weiterhin ein Aus- 
gabesteuerfeld umfaBt, in dem angegeben ist, ob das lokale Datenverarbeitungssystem die Kryptographieschlus- 
seifunktion ausgeben darf, und in dem ebenfalls angegeben ist, ob ein entferntes Datenverarbeitungssystem, mit 
dem das lokale Datenverarbeitungssystem verbunden ist, die KryptographieschlGsselfunktion zurGckleiten darf. 

Ein Verfahren gemaB Anspruch 6, bei dem der zugeordnete Steuervektor ein Typenfeld umfaBt, in dem angegeben 
ist, daB die Kryptographieschlusseifunktion Datenkryptographiefunktionen ausfGhren kann und weiterhin ein Sub- 
feld umfaBt, in dem angegeben ist, daB die KryptographieschlGsselfunktion Funktionen an personlichen Daten aus- 
fGhren darf. 

Ein Verfahren gemaB Anspruch 6, bei dem der zugeordnete Steuervektor ein Typenfeld umfaBt, in dem angegeben 
ist, daB die Kryptographieschlusseifunktion Datenkryptographiefunktionen ausfGhren kann und weiterhin ein Sub- 
f eld umfaBt, in dem angegeben ist, daB eine Verschlusselungstextauflosungsfunktion von der Kryptographieschlus- 
seifunktion ausgefGhrt werden darf. 

Ein Verfahren gemaB Anspruch 10, bei dem der zugeordnete Steuervektor werterhin ein Benutzerfeld umfaBt, in 
dem angegeben ist, daB die Kryptographieschlusseifunktion in einer Verschlusselungstextauflosungsfunktion als 
Ausgabedatenschlusselfunktion verwendet werden darf. 

Ein Verfahren gemaB Anspruch 9, bei dem die Datenkryptographiefunktion ein Sitzungsschutz ist, mit dem die 
Vertraulichkeit von Daten Gbertragun gen zwischen zwei Kommunikationseinrichtungen im System, die eine gemein- 
same Datenkodierungs-Adekodierungsschlusself unktion besitzen, mit der es jeder Einrichtung moglich ist, kodierte 
Daten zu senden und zu empfangen, gesichert ist, das folgende Schritte umfaBt: 

gemeinsame Nutzung einer DatenvertrauIichkeitsschlGsselfunktion zwischen den Einrichtungen; 

Speicherung der DatenvertraulichkeitsschlGsserfunktion in AusfGhrungsform, die an jeder der Einrichtungen 
unter einer Masterschlusselfunktion kodiert ist; 

Bereitsteliung von Verwendungsattributen f Or den steuervektor jeder DatenvertraulichkeitsschlGsself unktion zur 
VerschlGsselung bzw. Entschlusselung, wodurch jede SchlGsselfunktion zur Verschlusselung und Entschlus- 
selung verwendet werden kann. 

Ein Verfahren gemaB Anspruch 12, bei dem die Datenkryptographiefunktion ein Dateischutz ist, um die Vertrau- 
lichkeit von Datendateien zu schutzen, bei der ein einzelner Endbenutzer eine Datenkodierungs-7-dekodierungs- 
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schlusselfunktion besitzt, mit der Daten zur Speicherung kodiert und zum Zweck der Wiederhersteliung der Daten 
wieder dekodiert werden konnen, und das folgende Schritte umfaBt: 

Bereitstellung einer Datenvertraulichkeitsschlusselfunktion fur den einzelnen Endbenutzer; 

Speicherung einer kodierten Form der Datenvertraulichkeitsschlusselfunktion mit Daten, die durch diese 
Schlusselfunktion kodiert wurden; 

wobei die Datenvertraulichkeitsschlusseffunktion in Importform unter einer Schlusselfunktionnkodie- 
rungsschlusselfunktion zusammen mit ihrem zugeordneten Steuervektor gespeichert ist; 

Bereitstellung von Verwendungsattributen fur den Steuervektor der Datenvertraulichkeitsschlusselfunktion zur 
Verschlusselung und Entschlusselung, wodurch die Datendatei mit derselben Schlusselfunktion kodiert und 
dekodiert werden kann. 

14. Ein Verfahren gemaB Anspruch 12, bei dem die Daten (cryptograph iefunktion eine kodierte Mailbox ist, in der jeder 
Benutzer unter einer Mehrzahl von Benutzern des Systems eine Datenvertraulichkeitsschiusselfunktion in zwei 
Formen besitzt, wobei die erste Form eine Daten kodierung und die zweite Form eine Datendekodierung ermoglicht, 
wobei die erste Form der Schlusselfunktion in das offentliche Verzeichnis gesetzt wird, wo sie alien Benutzern der 
Mailbox zuganglich ist, so daB jede registrierte Schlusselfunktion unter einem Benutzeridentifikator aufgezeichnet 
ist, der dem Benutzer zugeordnet ist, der die Schlusselfunktion aufzeichnet, und wobei die zweite Form der Schlus- 
selfunktion personlich dem Benutzer zugeordnet ist, dem sie gehort, so daB Mail, das in die Mailbox gestellt wurde 
und fur einen bestimmten Benutzer in kodierter Form bestimmt ist, nur von diesem Benutzer - dem beabsichtigten 
Empfanger - dekodiert werden kann, das die folgenden Schritte umfaBt: 

Bereitstellung einer Datenvertraulichkertsschlusselfunktion, die in zwei Formen ersteilt wurde, wobei die erste 
Form nur eine Kodierung und die zweite Form nur eine Dekodierung ermoglicht; 

Bereitstellung von Steuervektor-Verwendungsattributen fur den Steuervektor, der der Datenvertraulichkeits- 
schlusselfunktion zugeordnet ist, die fur die erste Form der Datenvertraulichkeitsschlusselfunktion nur Ver- 
schlusselungsfunktionen und fur die zweite Form der Datenvertraulichkeitsschlusselfunktion nur Entschlusse- 
lungsfunktionen besitzt. 

15. Ein Verfahren gemaB Anspruch 12, bei dem die Datenkryptographiefunktion eine Verschlusselungstextauflo- 
sungsfunktion ist, die in einem Verschlusselungstextauflosungszentrum in einem Netzwerk im System ausgefuhrt 
werden soil und in der Lage ist, kodierte Daten von einer Kodierung unter einer ersten Datenschlusselfunktion in 
eine Kodierung unter einer zweiten Datenschlusselfunktion sicher aufzuldsen, das folgende Schritte umfaBt: 

Erzeugung einer Datenschlusselfunktion in zwei Formen an einer Mehrzahl an Geraten im Kommunikations- 
netzwerk, wobei die erste Form eine Datenvertraulichkeitsschlusselfunktion in Betriebsform mit einem zuge- 
ordneten Steuervektor, der Verschiusse lungs- und Entschlusselungsattribute besitzt, ist, und wobei die zweite 
Form der Datenschlusselfunktion eine Datenumwandlungsschlusselfunktion in Exportform ist, die fur den 
Export zu einem Verschlusseiungstextaufldsungszentrum im Netzwerk geeignet ist; 

Empfang der Datenaufldsungsschlusselfunktion am Verschlusselungstextauflosungszentrum und Umwand- 
lung der empfangenen Datenaufldsungsschlusselfunktion in eine Betriebsform, wobei der Steuervektor, der 
der Datenauflosungsschlusselfunktion zugeordnet ist, sowohl Auflosungsein- als auch Aufiosungs-aus- Attri- 
bute besitzt; 

Verschlusselung von Daten an einem ersten Gerat, die zum Verschlusselungstextauflosungszentrum gesendet 
werden, wo sie unter der zweiten Datenschlusselfunktion, die einem zweiten Gerat im Netzwerk, das mit dem 
VerschlOsselungstextauflosungszentrum verbunden ist, bekannt sind, in verschlusselte Form umgewandelt 
werden; 

Qbertragung der umgewandelten Daten vom Zentrum zum zweiten Gerat, wo sie unter der zweiten Daten- 
schlusselfunktion entschlusselt werden. 

16. Ein Verfahren gemaB Anspruch 15, wobei das Verschlusselungstextaufldsungszentrum empfangene, nach innen 
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gerichtete entschlOsselte Daten nicht entschlOsseln kann und auch Daten in einer Form, die mit nach auBen geri- 
cheteten, verschlusselten Daten vergleichbar sind, nicht versch (Ossein kann. 

17. Ein Verfahren gemaB Anspruch 1 2, wobei die Daten kryptographief unktion eine SuchverschlGsselungstextaufldsung 
fur eine Kommunikationsnetzwerkkette im System ist, das ein erstes Gerat umfaBt, welches eine Kommunikation 
beginnt, das mit einem Versch lusselungstextaufldsungszentrum verbunden ist, dasselbst wiederum mit einem zwei- 
ten Versch IGsselungstextaufldsungszent rum verbunden ist, das selbst wiederum mit einem zweiten Netzwerkgerat 
verbunden ist, und zur Obertragung verschlusselter Daten vom ersten Gerat uber das erste VerschlOsselungstext- 
auftosungszentrum und das zweite Verschlusselungstextaufldsungszentrum zum zweiten Gerat dient undfoigende 
Schrttte umfaBt: 

Erzeugung einer ersten DatenschlOsselfunktion im ersten Netzwerkgerat in zwei Formen, wobei die erste Form 
eine Datenvertraulichkeitsschtusself unktion in Betriebsform mit einem zugeordneten Steuervektor, der Ver- 
schlOsselungsattribute besitzt, ist, und wobei die zweite Form der ersten DatenschlGsselfunktion eine Daten- 
umwandlungsschlusselfunktion (ein) in Exportform ist, die fur den Export zum ersten VerschlGsselungstextauf- 
losungszentrum im Netzwerk geeignet ist; 

Erzeugung einer zweiten Datenschlusselfunktion im zweiten Netzwerkgerat in zwei Formen, wobei die erste 
Form eine Datenvertraulichkeitsschlusself unktion in Betriebsform mit einem zugeordneten Steuervektor, der 
Entschlusselungsattribute besitzt, ist, und wobei die zweite Form der zweiten Datenschlusselfunktion eine 
Daten umwandlungsschlOsself unktion (aus) in Exportform ist, die fur den Export zum zweiten Verschlusselungs- 
textauflosungszentrum im Netzwerk geeignet ist; 

Erzeugung einer dritten Datenschlusselfunktion im ersten VerschlOsselungstextauflosungszentrum in zwei For- 
men, wobei die erste Form eine DatenumwandlungsschlGsseifunktion (aus) und die zweite Form eine Daten- 
umwandlungsschlusselfunktion (ein) ist, die fur den Export zum zweiten VerschlOsselungstextaufld- 
sungszentrum im Netzwerk geeignet ist; 

wobei das erste Netzwerkgerat die erste Datenschlusselfunktion in ihrer zweiten Form als Datenumwandiungs- 
schlusself unktion (ein) zum ersten VerschlGsselungstextauflosungszentrum Obertragt; 

wobei das zweite Netzwerkgerat die zweite Datenschlusselfunktion in ihrer zweiten Form als Datenumwand- 
lungsschlOsselfunktion (aus) zum zweiten VerschlOsselungstextaufldsungszentrum Obertragt; 

wobei das erste Versch lOsselungstextauflosungszentrum die dritte Datenschlusselfunktion in ihrer zweiten 
Form als Datenumwandlungsschtusselfunktion (ein) zum zweiten Versch lOsselungstextauflosungszentrum 
Obertragt; 

wobei das erste Netzwerkgerat Daten unter der ersten DatenschlOsself unktion in der ersten Form verschlGsselt 
und wobei die verschlOsselten Daten zum ersten VerschlQsselungstextaufldsungszentrum Gbertragen werden, 
wo die Daten unter der ersten Datenschlusselfunktion in der zweiten Form aufgelost werden, weil sie unter der 
dritten DatenschiOsselfunklion in der ersten nach auBen umzuwandelnden Form verschlOsselt werden sollen, 
und zum zweiten Versch I usselungstextauflosungszentrum Obertragen werden, wo die Daten unter der dritten 
Datenschlusselfunktion in ihrer zweiten Form in eine unter der zweiten Datenschlusselfunktion in der zweiten 
Form verschlusselten Form umgewandelt werden, in der sie nach auBen umgewandett und zum zweiten Netz- 
werkgerat ubertragen werden, wo die Daten anschlieBend unter der zweiten DatenschlOsself unktion in ihrer 
ersten Form entschlusselt werden. 

18. Ein Verfahren gemaB Anspruch 12, bei dem die Datenkryptographief unktion auf eine verschlOsselte Datei unter 
einer ersten Schlusself unktion angewandt wird, so daB ein Teil der Datei unter einer zweiten Schlusself unktion zur 
Obertragung an einen beabsichtigten Empfanger zurOck verschlOsselt werden kann, ohne daB die gesamte ver- 
schlOsselte Datei offenbart werden muB, best eh end aus folgenden Schritten: 

Erzeugung einer ersten Datenschlusselfunktion in zwei Formen an einem ersten Gerat im System, wobei die 
erste Form eine DatenvertraulichkeitsschlOsse If unktion in Betriebsform und die zweite Form eine Datenum- 
wandlungsschlOsselfunktion (ein) ist; 

VerschlOsselung einer Datendatei unter Verwendung der Datenvertraulichkeitsschlusselfunktion und Speiche- 
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rung der Datei in ihrer verschlussetten Form im Datenspeicher; 

wobei das erste Gerat eine zweite Datenschlusself unktion in zwei Formen erzeugt, namlich als Datenumwand- 
iungsschlusself unktion (aus) und als Datenentschlusselungsschlusself unktion; 

Ubertragung der Datenentschlusselungsschlusself unktion an ein zweites Gerat im System, das mit dem ersten 
Gerat verbunden ist; 

Zugriff aut die Datendatei vom Datenspeicher aus und erneute Verschlusselung eines Teils der Datei von der 
Verschlusselung unter der ersten Datenschlusself unktion zur Verschlusselung unter der zweiten Datenschlus- 
selfunktion uber eine Anweisung zur Auflosung des VerschlOsselungstextes unter Verwendung der ersten 
Datenschlusself unktion in der Form der Datenumwandiungsschlusself unktion (ein) und unter Verwendung der 
zweiten Datenschlusself unktion in der Form der Datenumwandiungsschlusself unktion (aus) sowie Ubertragung 
des emeut verschlusselten Teils der Datendatei vom ersten Gerat zum zweiten Gerat; 

Entschlusselung des Obertragenen Teils der Datendatei in Form der Entschlusselungsschlussetform der zwei- 
ten Schlusselfunktion zur Verwendung am zweiten Gerat. 

19. Ein Verfahren gemaB Anspruch 12, bei dem die Datenkryptographief unktion Nachrichten integritat ist, in denen die 
Inhalte einer Nachricht gegen nicht autorisierte Anderungen geschutzt sind, bestehend aus folgenden Schrttten: 

Bereitstellung einer Daten/MAC-SchlOsself unktion und eines zugeordneten Steuervektors mit MAC-Generie- 
rungs- und MAC-Verifizierungsattributen an einer Sende- und an einer Empfangsstation in einem Kommunika- 
tionsnetzwerk im System; 

Berechnung eines MAC-Werts fur eine von der Sendestation zur Empfangsstation zu sendende Nachricht und 
Verwendung der Daten/MAC-Schlusselfunktion und des Steuervektors an der Sendestation; 

Ubertragung der Nachricht urid des berechneten MAC-Werts von der Sendestation zur Empfangsstation; 

Berechnung eines zweiten MAC-Werts zur empfangenen Nachricht an der Empfangsstation, Verwendung der 
Daten/MAC-Schlusselfunktion und des Steuervektors und Vergleich des zweiten berechneten MAC-Werts mit 
dem Obertragenen MAC-Wert; 

Uberprufung der Integritat der an der Empfangsstation empfangenen Nachricht, wenn die beiden berechneten 
MAC-Werte gleich sind. 

20. Verfahren gemaB Anspruch 12, bei dem die Datenkryptographief unktion Nachrichtenauthentifizierung mit Nichtzu- 
ruckweisung ist, bestehend aus folgenden Schritten: 

Bereitstellung einer Daten/MAC-Schlusselfunktion mit einem ersten zugeordneten Steuervektor mit 
MAC-Generierungssattribut an einer Sendestation in einem Kommunikationsnetzwerk im System; 

Bereitstellung einer Daten/MAC-Schlusselfunktion mit einem zweiten zugeordneten Steuervektor mit 
MAC-Verifizierungsattribut an einer Empfangsstation im Kommunikationsnetzwerk; 

Berechnung eines ersten Werts fur das MAC zur Nachricht, die von der Sendestation uber das Kommunikati- 
onsnetzwerk an die Empfangsstation gesendet werden soil, unter Verwendung der Daten/MAC-SchtOsselfunk- 
tion und des ersten Steuervektors an der Sendestation; 

Obertragung der Nachricht und des ersten MAC-Werts von der Sendestation uber das Kommunikationsnetz- 
werk zur Empfangsstation; 

Berechnung eines zweiten Werts fur das MAC zur Nachricht, die an der Empfangsstation empfangen wurde, 
unter Verwendung der Daten/MAC-Schlusselfunktion und des zweiten Steuervektors an der Empfangsstation; 

Sicherstellung, daB die Nachricht Integritat besitzt und da3 sie von der Sendestation gesendet wurde, wenn 
der erste Wert fur das MAC gleich dem zweiten Wert fur das MAC entspricht. 
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21 . Ein Verfahren gemaG Anspruch 1 2, wobei die Datenkryptographief unktion eine Suchverschlusselungstextaufldsung 
fur eine Kommunikationsnetzwerkkette im System ist, das ein schlusselfunktionsausgebendes Gerat im Netzwerk 
und ein erstes Gerat umfaBt, welches eine Kommunikation im Netzwerk beginnt, das mit einem ersten Verschlus- 
selungstextaufldsungszentrum verbunden ist, das selbst wiederum mit einem zweiten Verschlusselungstextaufld- 
sungszentrum verbunden ist, das selbst wiederum mit einem zweiten Netzwerkgerat verbunden ist, und zur Clber- 
tragung verschlusselter Daten vom ersten Gerat uber das erste Verschlusselungstextauflosungszentrum und das 
zweite Verschlusselungstextaufldsungszentrum zum zweiten Gerat dient und folgende Schritte umfaGt: 

Erzeugung einer ersten Datenschlusselfunktion im ersten Netzwerkgerat in zwei Formen, wobei die erste Form 
eine Datenvertraulichkeitsschlusselfunktion in Betriebsform mit einem zugeordneten Steuervektor, der Ver- 
schlusselungsattribute besitzt, ist, und wobei die zweite Form der ersten Datenschlusself unktion eine Daten- 
umwandlungsschlusself unktion (ein) in Exportform ist, die fur den Export zum ersten Verschlusselungstextauf- 
losungszentrum im Netzwerk geeignet ist; 

Erzeugung einer zweiten Datenschlusself unktion im zweiten Netzwerkgerat in zwei Formen, wobei die erste 
Form eine Datenvertraulichkeitsschlusseffunktion in Betriebsform mit einem zugeordneten Steuervektor, der 
Entschlusselungsattribute besitzt, ist, und wobei die zweite Form der zweiten Datenschlusself unktion eine 
Datenumwandlungsschlusself unktion (aus) in Exportform ist, die fur den Export zum zweiten Verschlusselungs- 
textauflosungszentrum im Netzwerk geeignet ist; 

Erzeugung einer dritten Datenschlusself unktion im schlusselfunktionsausgebenden Gerat in zwei Formen, 
wobei die erste Form eine Datenumwandlungsschlusselfunktion (aus) ist, die fur den Export zum ersten 
Verschiusselungstextaufldsungszentrum im Netzwerk geeignet ist, und wobei die zweite Form eine Datenum- 
wandlungsschlusselfunktion (ein) ist, die fur den Export zum zweiten Verschlusselungstextauflosungszentrum 
im Netzwerk geeignet ist; 

wobei das erste Netzwerkgerat die erste Datenschlusself unktion in ihrer zweiten Form als Datenumwandlungs- 
schlusself unktion (ein) zum ersten Verschlusseiungstextauflosungszentrum ubertragt; 

wobei das zweite Netzwerkgerat die zweite Datenschlusself unktion in ihrer zweiten Form als Datenumwand- 
lungsschlusself unktion (aus) zum zweiten Verschlusselungstextaufldsungszentrum ubertragt; 

wobei das erste schiusselfunktionsausgebende Gerat die dritte Datenschlusself unktion in ihrer ersten Form als 
Datenumwandlungsschlusselfunktion (aus) zum ersten Verschlusselungstextauflosungszentrum ubertragt und 
wobei das erste schiusselfunktionsausgebende Gerat die dritte Datenschlusself unktion in ihrer zweiten Form 
als Datenumwandlungsschlusself unktion (ein) zum zweiten Verschlusselungstextauflosungszentrum ubertragt; 

wobei das erste Netzwerkgerat Daten unter der ersten Datenschlusself unktion in der ersten Form verschlusselt 
und wobei die verschlusselten Daten zum ersten Verschlusselungstextauflosungszentrum ubertragen werden, 
wo die Daten unter der ersten Datenschlusself unktion in der zweiten Form aufgelost werden, weil sie unter der 
dritten Datenschlusselfunktion in der ersten nach auGen umzuwandelnden Form verschlusseit werden sollen, 
und zum zweiten Verschlusselungstextauflosungszentrum ubertragen werden, wo die Daten unter der dritten 
Datenschlusselfunktion in ihrer zweiten Form in eine unter der zweiten Datenschlusselfunktion in der zweiten 
Form verschlusselten Form umgewandelt werden, in der sie nach auGen umgewandelt und zum zweiten Netz- 
werkgerat ubertragen werden, wo die Daten anschlieGend unter der zweiten Datenschlusselfunktion in ihrer 
ersten Form entschlussett werden. 

22. Ein Datenverarbeitungssystem, das Kryptographiedienstanforderungen zur Ausfuhrung von Datenkryptographie- 
funktionen an Daten verarbeitet, unter Verwendung von Kryptographieschlusselfunktionen, denen Steuervektoren 
zugeordnet sind, die die Funktionen definieren, die jede Taste gemaG Definition durch ihren Definierer ausfuhren 
dart, bestehend aus folgenden Komponenten: 

einer Kryptographieeinrichtung (4) mit einer sicheren Begrenzung (6), durch die ein Eingabepfad (8) fur den 
Empfang der Kryptographiedienstanforderung, der Daten, der Kryptographieschlusselfunktionen und ihrer 
zugeordneten Steuervektoren und ein Ausgabepfad (8) fur die Bereitstellung von Antworten lauft, wobei inner- 
halb der Begrenzung (6) ein Kryptographieanweisungsspeicher (10), der an den Eingabepfad gekoppelt ist, 
ein Steuervektorprufmittel (14) und ein Kryptographieverarbeitungsmittel (16), das an den Anweisungsspeicher 
gekoppelt ist, sowie ein Masterschlusselfunktionsspeicher (18), der an das Verarbeitungsmittel (16) gekoppelt 
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ist, enthalten sind, um eine sichere Position zur Ausfuhrung von Datenkryptographiefunktionen als Reaktion 
auf die empfangenen Dienstanforderungen bereitzustellen; 

wobei der Kryptographieanweisungsspeicher (10) uber den Eingabepfad (8) eine Kryptographiedienstanforde- 
rung zur Ausfuhrung einer Datenkryptographiefunktion auf einer Kryptographietaste empfangt; 

wobei das Steuervektorprufmittel (14) einen Eingang besitzt, der an den Eingabepfad (8) gekoppelt ist, um 
einen Steuervektor (Figur 5) zu empfangen, der der Kryptographieschlusselfunktion zugeordnet ist, und einen 
weiteren Eingang besitzt, der an den Kryptographieanweisungsspeicher (10) gekoppeit ist, um Steuersignaie 
zu empfangen, mit denen sichergestellt werden kann, dafi der Steuervektor die Datenkryptographiefunktion 
autorisiert, die von der Kryptographiedienstanforderung angefordert wurde; 

wobei das Steuervektorprufmittel (14) eine Autorisierungsausgabe (20) besitzt, die an einen Eingang des Kryp- 
tographieverarbeitungsmittels (16) gekoppelt ist, um anzuzeigen, daB die Datenkryptographiefunktion autori- 
siert ist, deren Empfang im Kryptographieverarbeitungsmittei (16) die Ausfuhrung der angeforderten Daten- 
kryptographiefunktion mit der Kryptographieschlusselfunktion auslost. 



Revendlcatlons 

1. Un procede de validation du fait que des fonctions de cryptographie de donnees, requises pour un cl6 de crypto- 
graphie, ont ete autorisees par ('element a I'origine de la cle, dans un systeme informatique traitant des requetes 
de services de cryptographie pour effectuer des fonctions de cryptographie de donnees, sur des donnees, par 
utilisation de cles de cryptographie associees a des vecteurs de commande definissant les fonctions que chaque 
cle est autorisee a effectuer par I'element d'origine, comprenant les etapes consistant a : 

- recevoir une requete de service cryptographique pour executer une fonction de cryptographie de donnees, sur 
des donnees, par utilisation cfune cle cryptographique dans une ressource cryptographique (4), ayant une 
frontiere sure (6) a travers laquelle passent un chemin d'entree et un chemin de sortie (8); 

- recevoir un vecteur de commande (figure 5) associe a la cle cryptographique et controler (14) que le vecteur 
de commande autorise la fonction cryptographique de donnees requise par la requete de service cryptogra- 
phique; et 

- signaler (20) que la fonction cryptographique de donnees est autorisee et commencer a effectuer la fonction 
cryptographique de donnees requise a ('aide de la cle cryptographique. 

2. Un precede selon la revendication 1 , comprenant en outre le stockage dans un moyen de stockage (22) de la c\6 
cryptographique, sous une forme cryptee, sous laquelle la cle cryptographique est cryptee sous une cle de stockage 
qui est le produit logique du vecteur de commande assocte et d'une cle martre (18). 

3. Un precede selon la revendication 2, dans lequel la cle de stockage est !e produit logique OU exclusif du vecteur 
de commande associe et de la cle maitre stockee dans la memoire de stockage de cle mattre. 

4. Un precede selon I'une quelconque des revendications precedentes, dans lequel le vecteur de commande associe 
est stocke avec la forme cryptee de la c!6 cryptographique, dans le moyen de stockage de cle cryptographique. 

5. Un procedS selon Tune quelconque des revendications precedentes, dans lequel le vecteur de commande associe 
comprend des zones definissant des types autorises de fonctions cryptographiques comprenant des fonctions de 
gestion de cles, des fonctions de cryptographie de donnees et des fonctions de traitement PIN (Numero d'ldentifi- 
cation Personnel), et les fonctions de cryptographie de donnees dont le type est defini. 

6. Un precede selon I'une quelconque des revendications precedentes, dans lequel le vecteur de commande associe 
comprend des zones definissant la commande et ('utilisation de la fonction export. 

7. Un precede selon la revendication 6, dans lequel le vecteur de commande associe comprend en outre une zone 
d'utilisation definissant Tune des proprtetes ci-apres disant : 
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que la cle* cryptograph ique peut effect uer le cryptage des donnees; 

que la cle* cryptographique ne peut effectuer le cryptage des donn6es; 

que la cle* cryptographique peut effectuer la description des donnSes; 

que la cle* cryptographique ne peut effectuer la description des donnees; 

que la cle* cryptographique peut effectuer des fonctions de cryptograph ie de donnees; 

- que la cle* cryptographique peut effectuer des fonctions d'authentification de messages; 

que la cle* cryptographique peut Stre utilised pour gendrer un code d'authentification de messages concemant 
les don n des; 

que la cl6 cryptographique ne peut §tre utilised pour g6n6rer un code d'authentification de messages concemant 
les donnees; 

que la cle* cryptographique peut 6tre utilised pour verifier un code d'authentification de messages concemant 
les donnees; 

- que la cle* cryptographique ne peut §tre utilised pour verifier un code d'authentification de messages concemant 
les donnees; 

- que la cl6 cryptographique ne peut etre utilises comme cl6 de donnees de sortie dans une fonction de traduction 
de texte codd; 

- que la cl6 cryptographique peut dtre utilised comme cl6 de donn6es de donnees d'entr6e dans une fonction 
de traduction de texte crypt6; 

- que la cle> cryptographique ne peut §tre utilised comme cl6 de donnees d'entr6e dans une fonction de traduction 
de texte crypt6; 

que la c\6 cryptographique peut effectuer des fonctions de cryptographic de donnees et comprend en outre 
une zone de sous-type, d6finissant que la cle* cryptographique est une cle* de donnees ANSI (American National 
Standards Institute). 

8. Un proc£d6 selon la revendication 6, dans lequel le vecteur de commande associe comprend une zone de type 
d6finissant que la cle" cryptographique peut effectuer des fonctions de cryptograph ie de donnees et comprend en 
outre une zone de commande d'export definissant si le systeme informatique local est autorise a exporter la cie 
cryptographique et definit en outre si un systeme informatique deportd, auquel le systeme informatique local est 
connect^ est autorise a re-exporter la cle* cryptographique. 

9. Un precede selon la revendication 6, dans lequel le vecteur de commande associe comprend une zone de type 
definissant que la cie cryptographique peut effectuer des fonctions de cryptographie de donnees et comprend en 
outre une zone de sous-type d6finissant que la cle cryptographique peut effectuer des fonctions de confidentialite 
de donnees. 

10. Un procecie* selon la revendication 9, dans lequel le vecteur de commande associe comprend une zone de type 
definissant que la cle* cryptographique peut effectuer des fonctions de cryptographie de donnees et comprend en 
outre une zone de sous-type d6finissant qu'une fonction de traduction de texte crypte" peut Stre effective par la cle 
cryptographique. 

11. Un proc6d6 selon la revendication 10, dans lequel le vecteur de commande associe comprend en outre une zone 
d'utilisation d6finissant que la cl6 cryptographique peut etre utilis6e comme c!6 de donnees de sortie dans une 
fonction de traduction de texte crypte. 

12. Un proc6d6 selon la revendication 9, dans lequel la fonction de cryptographie de donnees est destine* a assurer la 
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protection d'une session, afin de prot6ger la confidentiality des transmissions de donnyes entre deux dispositifs en 
communication dans le systeme partageant une ciy commune de cryptageAtecryptage de donnyes, permettant a 
chaque dispositif a ia fois cfenvoyer et de recevoir des donnees cryptyes, comprenant les ytapes consistant a : 

partager une ciy de confidentiality de donnyes entre les dispositifs; 

stocker la ciy de confidentiality de donndes sous une forme ope" rationnelle cryptye sous une ciy maTtre a chaque 
dispositif respectif; 

mettre a disposition des attributs d'utilisation pour le vecteur de commande de chaque ciy de confidentiality de 
donnyes, afin de respectivement crypter et decrypter, permettant a chaque ciy d'etre utilises a la fois pour 
crypter et pour decrypter des donnyes. 

13. Un procedy selon la revendication 12, dans lequel la fonction de cryptographie de donnyes est destinee a proteger 
des fichiers, pour proteger la confidentiality de fichiers de donnees, dans lequel un utilisateur final unique possede 
une cle de cryptage/decryptage de donnees, permettant a des donnyes d*§tre cryptyes en vue d'un stockage et 
d'fitre d6cryptees aux fins de r6cup6ration du fichier, comprenant en outre les Stapes consistant a : 

fournir une cle de confidentiality de donnyes a I'utilisateur final individuel; 

stocker une forme cryptye de la ciy de confidentiality de donnyes avec des donnyes ayant yty cryptyes de 
cette mani^re; 

stocker la ciy de confidentiality de donnyes sous une forme d'import, cryptye sous une ciy de cryptage de ciy, 
avec son vecteur de commande associy; 

fournir des attributs . d'utilisation pour le vecteur de commande de la ciy de confidentiality de donnyes afin de 
crypter et de decrypter, de maniyre a permettre au fichier de donnyes d'Stre a la fois crypty et dycrypty par la 
meme ciy. 

14. Un procydy selon la revendication 12, dans lequel la fonction de cryptographie de donnyes est une bolte a lettres 
cryptye, dans laquelle chaque utilisateur parmi une plurality d'utilisateurs du systdme a une ciy de confidentiality 
de donnees se prysentant sous deux formes, la prendre forme permettant le cryptage des donnyes et la deuxiyme 
forme permettant le dycryptage des donnyes, la premiere forme de la ciy ytant placed dans le rypertoire public 
accessible a tous les utilisateurs de la boite a lettres, de manifere que chaque ciy enregistrye le sort sous un tden- 
tificateur d'utilisateur appartenant a I'utilisateur qui enregistre la ciy, la deuxieme forme de la ciy ytant privye a 
i'utilisateur auquel elle appartient, de sorte qu'un courrier dyposy dans la boite aux lettres et concernant un utilisateur 
particuiier, sous sa forme cryptye, puisse etre dycrypty seulement par cet utilisateur - le recepteur dysigny - com- 
prenant les ytapes consistant a : 

fournir une ciy de confidentiality de donnyes ayant yty gynyrye sous deux formes, la premiere forme permettant 
le cryptage seulement et la deuxiyme forme permettant le dycryptage; 

fournir des attributs d'utilisation de vecteur de commande pour le vecteur de commande associe a la ciy de 
confidentiality de donnyes, ayant pour la premi6re forme de ciy de confidentiality de donnyes seulement des 
caractdristiques de cryptage et qui a pour la deuxiyme forme de ciy de confidentiality de donnees des carac- 
tyristiques de dycryptage. 

15. Un procydy selon la revendication 12, dans lequel la fonction de cryptographie de donnyes est une fonction de 
traduction de texte crypty devant etre effect uye en un centre de traduction de textes cryptys se trouvant dans un 
ryseau dans le systeme susceptible de traduire de facon sure des donnyes cryptyes, i'ayant yty sous une premiere 
ciy de donnyes, pour assurer un cryptage sous une deuxiyme ciy de donnyes, comprenant les ytapes consistant a : 

gynerer une ciy de donnyes sous deux formes, en une plurality de dispositifs situys dans le ryseau de com- 
munication, la premiere forme ytant une ciy de confidentiality de donnyes qui a sous forme opyrattonnelle un 
vecteur de commande associy qui comporte des attributs de cryptage et de dycryptage, et la deuxiyme forme 
de ciy de donnyes ytant une ciy de traduction de donnyes sous forme d'export, appropriye pour exporter vers 
un centre de traduction de texte crypty se trouvant dans le ryseau; 
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recevoir la cle de traduction de donnees au centre de traduction de textes cryptes et convertir la cte de traduction 
de donnees recue sous une forme operationnelle, le vecteur de commande associe a la cle de traduction de 
donnees ayant ies deux attributs de traduire en mode theme et en mode version; 

crypter des donndes en un premier dispositif quelconque, ayant 6t6 transmise au centre de traduction de textes 
cryptes ou elles sont traduites par cryptage, sous la deuxieme c\6 de donn6es connue, en un deuxieme dispositif 
se trouvant dans le reseau et reli6 au centre de traduction de textes cryptes; 

transmettre Ies donndes traduites du centre au deuxieme dispositif ou elles sont decrypted sous la deuxieme 
cle de donnees. 

16. Un proc6d6 selon la revendication 15, dans lequel le centre de traduction de textes cryptes ne peut decrypter des 
donn6es cryptees entrantes ayant <§te recues, ni ne peut crypter des donnees se trouvant sous une forme compa- 
rable a des donnees crypte es sortantes. 

17. Un proc6d6 selon ia revendication 12, dans lequel la fonction de cryptographie de donnees est une traduction de 
texte crypte parity a parite, destinee a une chaTne de reseaux de communication dans le systeme, comprenant un 
premier dispositif emettant une communication, relie* a un premier centre de traduction de textes cryptes qui, a son 
tour, est relie" a un deuxieme centre de traduction de textes cryptes qui, a son tour, est reli6 a un deuxieme dispositif 
de reseaux, pour effectuer la transmission de donnees cryptees depuis le premier dispositif, en passant par ies 
premier et deuxieme centres de traduction de textes cryptes, pour aller au deuxieme dispositif, comprenant Ies 
6tapes consistant a : 

gen6rer une premiere ci6 de donnees dans le premier dispositif de r6seaux, sous deux formes, la premiere 
forme 6tant une cle" de confidential ite de donn6es sous forme op6rationnelle ayant un vecteur de commande 
associe qui a des attributs de cryptage, et la deuxieme forme de la del de donnees 6tant une cte de traduction 
en mode theme de donn6es, sous forme export, convenant pour Pexport vers le premier centre de traduction 
de textes cryptes; 

gen6rer une deuxieme c!6 de donndes dans le deuxieme dispositif de teseaux, sous deux formes ; la premiere 
forme etant une cle de confidentialite de donndes sous forme op6rationnelle ayant un vecteur de commande 
associe" comportant des attributs de decryptage, et la deuxieme forme de la deuxieme cle" de donnees 6tant 
une cle" de traduction de donnees sous mode version, sous forme export, convenant pour exporter vers le 
deuxieme centre de traduction de textes cryptes; 

geYterer une troisieme cte de donnees dans le premier centre de traduction de textes cryptes, sous deux formes, 
la premiere forme 6tant une cle de traduction de donnees sous mode version et la deuxieme forme elant une 
cle" de donndes de traduction sous mode theme, convenant pour exporter vers le deuxieme centre de traduction 
de textes cryptes; 

le premier dispositif de reseaux transmettant la premiere cl6 de donn6es sous sa deuxieme forme, a titre de 
cl6 de traduction en mode theme vers le premier centre de traduction de textes cryptes; 

le deuxieme dispositif de teseaux transmettant la deuxieme cte de donnSes sous sa deuxieme forme, a titre 
de cte de traduction en mode version, vers le deuxieme centre de traduction de textes cryptes; 

le premier centre de traduction de textes cryptes transmettant la troisieme cle" de donnees sous sa deuxieme 
forme, a titre de cl6 de traduction en mode theme, vers le deuxieme centre de traduction de textes crypt ds; 

Le premier dispositif de reseaux cryptant des donnees sous la premiere cle" de donn6es sous la premiere forme 
et transmettant Ies donnees cryptees au premier centre de traduction de teintes cryptes dans lequel Ies donn6es 
sont traduites sous la premiere cie* de donnees, dans la deuxieme forme pour dtre cryptees sous la troisieme 
cle" de donnees sous la premiere forme et traduites en mode version et transmises au deuxieme centre de 
traduction de textes cryptes, dans lequel Ies donn6es sont traduites sous la troisieme cl6 de donn6es, sous sa 
deuxieme forme, sous une forme cryptee sous la deuxieme cl6 de donnees, sous la deuxieme forme, dans 
laquelle Ies donn6es sont traduites en mode version et transmises au deuxieme dispositif de teseaux, dans 
lequel Ies donnees sont ensuite decryptees sous la deuxieme c!6 de donnees, sous sa premiere forme. 
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18. Un precede selon la revendication 12, dans lequel la fonction de cryptographie de donnees est appliquee a un 
fichier crypte sous une premiere cie, de maniere qu'une partie du fichier puisse etre recryptee sous une deuxieme 
cle\ en vue de la transmission a un recepteur auquel il est destine, sans r6veier la totality du fichier crypte, com- 
prenant les etapes consistant a : 

g6n6rer une premiere cl6 de donnees sous deux formes, en un premier dispositif dans le systeme, la premiere 
forme 6tant une cl6 de confidentialite de donnees stock6e sous forme operation ne lie et la deuxieme forme 
6tant une cie de traduction en mode theme des donnees; 



crypter un fichier de donnees en utilisant la cie de confidentiality de donnees et en stockant le fichier sous sa 
forme cryptee dans un dispositif de stockage de donnees; 



le premier dispositif g6n6rant une deuxieme c!6 de donnees sous deux formes, une cl6 de traduction en mode 
version et une cie de decryptage de donnees; 

transmettre la cie de decryptage de donn6es a un deuxieme dispositif dans le systeme, relie au premier dis- 
positif; 

acceder au fichier de donnees depuis le dispositif de stockage de donnees et recrypter une partie du fichier, a 
partir du cryptage fait sous la premiere cie de donnees, pour crypter sous la deuxieme cie de donn6es, par 
I'intermediaire d'une instruction de traduction de textes cryptes utilisant la premiere cl6 de donnees sous la 
forme de traduction en mode theme, et la deuxieme cie de donnees sous forme de traduction en mode version, 
et transmettre la partie recryptee du fichier de donnees du premier dispositif au deuxieme dispositif; 



25 dScrypter la partie transmise du fichier de donnees au moyen de la forme de cie de decryptage de la deuxieme 

cie, pour utilisation sur le deuxieme dispositif. 

19. Un precede selon la revendication 1 2, dans lequel la fonction de cryptographie de donnees concerne I'integrite des 
messages, dans lequel le contenu d'un message est protege contre toute modification non autorisde, comprenant 
30 les etapes consistant a : 



foumir une cie de donn6es/ordinateur multi-acces (MAC) et un vecteur de commando associe ayant des attri- 
buts de generation d'un MAC et de verification d'un MAC, a la fois en un poste emetteur et un poste r6cepteur 
dans un r6seau de communication dans le systeme; 

35 

cafculer une valeur de MAC pour un message devant etre envoy6 depuis le poste emetteur au poste recepteur 
en utilisant la cle donnees/MAC et le vecteur de commande au poste emetteur; 

transmettre le message et la valeur de MAC calcuiee du poste emetteur au poste recepteur; 

40 

calculer une deuxieme valeur de MAC sur le message recu au poste recepteur, utiliser la cie donnees/MAC et 
du vecteur de commande et effectuer la comparaison entre la deuxieme valeur calcuiee de MAC avec la valeur 
de MAC transmise; 



verifier I'int6grite du message regu au poste recepteur lorsque les deux valeurs MAC calcuiees sont 6gales. 

20. Un precede selon la revendication 12, dans lequel la fonction de cryptographie de donnees concerne Pauthentifi- 
cation de messages dans des conditions de non repudiation, comprenant les etapes consistant a : 

fournir une cl6 donnees/MAC avec un premier vecteur de commande associe ayant un attribut de generation 
de MAC en un poste emetteur dans un rdseau de communication dans le systeme; 

fournir !a cle donnees/MAC avec un deuxieme vecteur de commande ayant un attribut de verification MAC 
mais n'ayant pas un attribut de generation de MAC, en un poste recepteur dans le r6seau de communication; 

calculer une premidre valeur pour le MAC concernant un message devant §tre envoye par te poste emetteur 
sur le r6seau de communication, au poste recepteur, en utilisant la cie donnees/MAC et le premier vecteur de 
commande au poste emetteur, 
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transmettre le message et la premiere valeur MAC du poste emetteur sur le reseau de communication au poste 
recepteur; 

calculer une deuxieme valeur du MAC concernant le message recu au poste recepteur, en utilisant la cle don- 
nees/MAC et le deuxieme vecteur de commande, au poste recepteur; 

verification que le message a toute son integrate et qu'il a et6 envoye par le poste emetteur, lorsque la premiere 
valeur concernant le MAC est egale a la deuxieme valeur concernant le MAC. 

21. Un proced6 selon la revendication 12, dans lequel la fonction de cryptographie de donnees est une traduction de 
textecrypte, de parite a parrte, pour un reseau de communication dans le systeme, comprenant un dispositif demis- 
sion de c\6 dans le reseau, un premier dispositif qui emet une communication, relie a un premier centre de traduction 
de textes cryptes qui, a son tour, est relie a un deuxieme centre de traduction de textes cryptes qui, a son tour, est 
relie a un deuxieme dispositif de reseaux, pour effectuer la transmission de donnees cryptees depuis le premier 
dispositif par les premier et deuxieme centres de traduction de textes cryptes, au deuxieme dispositif, comprenant 
les etapes consistant a : 

generer une premiere cle de donnees dans le premier dispositif de reseau, sous deux formes, la premiere forme 
etant un cle de confidentialite de donnees sous forme operationnelle ayant un vecteur de commande associe 
ayant des attributs de cryptage et une deuxieme forme de la premiere cle de donnees etant une c\6 de traduction 
de donnees en mode theme sous la forme export, convenant pour exporter vers le premier centre de traduction 
de textes cryptes; 

generer une deuxieme cle de donnees dans le deuxieme dispositif de reseaux sous deux formes, la premiere 
forme elant une c 16 de confidentiality de donnees sous forme operationnelle ayant un vecteur de commande 
associe qui a des attributs de decryptage, et la deuxieme forme de la deuxieme cle de donnees etant une cle 
de traduction de donnees sous mode version, sous forme export, convenant pour exporter vers le deuxieme 
centre de traduction de teintes cryptes; 

geYidrer une troisieme c\6 de donnees dans le dispositif d'emission de cle, sous deux formes, la premiere forme 
etant une cle de traduction de donnees sous mode version convenant pour exporter vers le premier centre de 
traduction de donnees cryptees et la deuxieme forme elant une cl6 de donnees de traduction en mode theme, 
convenant pour exporter vers le deuxieme centre de traduction de textes cryptes; 

le premier dispositif de reseaux transmettant la premiere cle de donnees sous sa deuxieme forme a titre de cle 
de traduction en mode theme au premier centre de traduction de textes cryptes; 

le deuxieme dispositif de reseaux transmettant la deuxieme c\6 de donnees sous sa deuxieme forme, a titre 
de cle de traduction en mode version, vers le deuxieme centre de traduction de textes cryptes; 

le premier dispositif emetteur de cle transmettant la premiere cle de donnees sous sa premiere forme a titre 
de c!6 de traduction en mode version, vers le premier centre de traduction de textes cryptes, et transmettant 
la troisieme cle de donnees sous la deuxieme forme, a titre de cle de traduction en mode theme, au deuxieme 
centre de traduction de textes cryptes; 

le premier dispositif de reseaux cryptant des donnees sous la premiere cle de donnees sous sa premiere forme 
et transmettant les donnees cryptees au premier centre de traduction de textes cryptes dans lequel des donnees 
sont traduites sous la premiere cl6 de donnees sous la deuxieme forme, pour etre encryptees sous la troisieme 
cle de donnees sous la premifcre forme et dtre traduites en mode version et transmises au deuxieme centre de 
traduction de textes cryptes, lorsque les donnees sont traduites sous la troisieme cle de donnees sous la 
deuxieme forme, sous une forme cryptee, sous la deuxieme cle de donnees, sous la deuxieme forme 
lorsqu'etles sont traduites en mode version et transmises au deuxieme dispositif de reseau, dans lequel les 
donnees sont ensuite decrypt6es sous la deuxieme cl6 de donnees, sous la premiere forme. 

22. Un systeme de traitement de donnees traitant des requetes de services cryptograph iques pour effectuer des fonc- 
tions de cryptographie de donnees, sur des donnees, par utilisation de cles cryptograph iques associees a des 
vecteurs de commande d6finissant les fonctions que chaque cle est autoris6e a effectuer par son element d'origine, 
comprenant : 
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une ressource cryptographique (4), ayant une frontiere sQre (6), par laquelle passent un chemin d'entrSe (8) 
pour recevoir les requites de services cryptographiques, des donnSes, des ctes cryptographiques et leurs 
vecteurs de commande assoctes, et un chemin de sortie (8) pour y fournir des rSponses, 6tant inclus dans la 
frontiere (6) un stockage d'instructions cryptographiques (10) coupl6 au chemin d'entr6e, un moyen de contrSle 
de vecteurs de commande (14) et un moyen de traitement cryptographique (16) couple au stockage d'instruc- 
tions et un stockage de cle* maTtre (18) couple au moyen de traitement (16), pour fournir un emplacement sOr 
ou ex^cuter des fonctions de cryptographie de donnSes en rSponse aux requetes de services recues ; 

le stockage d'instructions cryptographiques (10) recevant par le chemin d'entrSe (8) une requete de service 
cryptographique pour ex6cuter une fonction cryptographique de donnees avec une cl6 cryptographique; 

le moyen de contrdle de vecteurs de commande (14) ayant une entr6e coupl6e au chemin d'entr6e (8) pour 
recevoir un vecteur de commande (figure 5) associ6 a la cl6 cryptographique et une entree couplde au stockage 
d'instructions cryptographiques (10), pour recevoir des signaux de commande pour initialiser le contrCle destine" 
a verifier que le vecteur de commande autorise la fonction de cryptographie de donnSes requise par la requite 
de services cryptographiques; 

le moyen de controle de vecteurs de commande (14) ayant une sortie d'autorisation (20) couptee a une entree 
du moyen de traitement cryptographique (16) pour signaler que la fonction de cryptographie de donn6es est 
autorisde, dont la reception par le moyen de traitement cryptographique (16) initialise !e fonctionnement de la 
fonction de cryptographie de donnees requise avec la cl6 cryptographique. 
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